DESIGN PROBLEMS
Frontend system design problems
144 problems ready now. Each one is an in-depth guide: the design built up step by step, every big decision weighed against the alternatives, with hand-drawn diagrams, interactive labs, exercises to check your understanding, and a self-check for your level.
144 problems
- #1Design an autocompleteA reusable text box that suggests matches as people type, for product search, a people picker, or a country field. The hard parts are deciding when to ask the server, never showing answers for an older query, caching what was already seen, the combobox pattern for keyboard and screen reader users, a popup that fits any screen, and text input in every language without slowing down typing.
- #2Design an accordionA design-system accordion: a stack of headings that each show or hide a panel. Toggling is easy; the real work is knowing when not to hide content, the right semantics (a button in a heading, or native details and summary), single versus multiple open with a controlled API, animating height to auto, keeping hidden text findable with find-in-page, opening the panel named in the URL, lazy panel content, and server rendering without layout shift.
- #3Design a tabs componentA design-system tabs component that shows one panel at a time. The row of buttons is easy; the real work is a clean compound API, the WAI-ARIA tabs pattern with roving focus and the right activation mode, ids that survive server rendering, deciding when hidden panels stay mounted, syncing the selected tab with the URL, loading data per tab without races, an animated indicator, and tab rows that don't fit on a phone.
- #4Design a tooltipA design-system tooltip: a short line of text that describes a button or icon when you point at it or reach it with the keyboard. Showing a box is easy; the real work is knowing what a tooltip must never hold, wiring the ARIA so screen readers hear it, meeting WCAG's hover rules (dismissible, hoverable, persistent), timing it with delays and a warm-up group, keeping it on screen inside scroll containers, rendering it above everything without z-index fights, and handling touch screens that have no hover at all.
- #5Design a star rating widgetA design-system star rating: a read-only display that shows an average like 4.3 out of 5 with its review count, and an input where a person picks their own 1 to 5 stars. The hard part is that these are two different components with different semantics: the display is an image with a label and a fractional fill, the input is a radio group with arrow keys, hover preview, form integration, a way to clear, and an optimistic save.
- #6Design a toast notification systemA toast system for a design system: small messages like "Saved" or "Message deleted. Undo" that slide in, wait, and leave on their own. Drawing one is easy; the hard parts are an API any code can call, a store outside React, a queue with a visible limit, fair timing that pauses for the reader, Undo that commits only on expiry, and announcements screen readers actually hear.
- #7Design a modal dialogA reusable modal dialog for a design system: a confirm box, a sign-in form, a settings sheet. It looks like a box on a dark overlay, but the hard parts are moving focus in and back out, making the rest of the page unreachable, clear closing rules, scroll locking, stacking, animation, phones, and the URL.
- #8Design a pagination controlThe numbered page control under search results, tables and listings. Drawing the buttons is easy; the real work is the page window algorithm that never jumps in width, keeping the page in the URL as real links, living with totals that are expensive or unknown, fetching pages without flashes or races, a compact mobile mode, and a control that screen reader and keyboard users can follow.
- #9Design breadcrumbsThe trail of links that says where a page sits in a big hierarchy, like a GitHub file path or a Drive folder path. Drawing a few links is easy; the real work is deriving the trail from routes and data, naming dynamic segments without layout shift, correct landmark and aria-current markup, collapsing long trails on a phone, and matching structured data for search.
- #10Design an OTP inputThe 6-digit verification code field shown after a code arrives by SMS, email, or an authenticator app. It looks like six boxes, but the hard parts are hidden: one real input versus six, autofill from the keyboard and the WebOTP API, paste with spaces and dashes, auto-submit without double submits, wrong codes, attempts, a resend cooldown, and a field a screen reader can use.
- #11Design a custom select dropdownA design-system select that picks a value, and its cousin the menu button that runs an action. A button and a list look easy; the hard parts are choosing the right pattern, the ARIA roles, a full keyboard model with typeahead, placing the popup near screen edges and inside scrolling containers, long and async option lists, phones, and plain HTML forms.
- #12Design an image carouselA reusable carousel that shows one or a few images at a time, for a product gallery, a home page hero, or the photos in a feed post. The hard parts are a layout that swipes smoothly, mounting only the slides that matter, loading images fast without layout shift, telling a swipe from a scroll, looping without glitches, autoplay that respects people, and the ARIA carousel pattern.
- #13Design a date pickerA design-system date picker for single dates and date ranges, with a typed field and a popup calendar. A grid of numbers looks easy; the hard parts are storing a date without a time zone bug, typing dates in every locale, a full keyboard and screen reader model, the popup, range rules, and phones.
- #14Design an infinite scroll listA reusable list component that loads the next page by itself as the reader nears the end. It looks like one observer and one fetch, but the hard parts are choosing it over pagination at all, firing the load early and exactly once, paging a list that changes under you, bringing people back to the same spot after a back click, keeping the page light after 1,000 items, and making it work for keyboards, screen readers, and search engines.
- #15Design a file uploaderA reusable upload component like the ones in Google Drive, Gmail, Slack and Dropbox: pick, drop, paste or choose a folder, check each file before it leaves the device, show previews, and send many files at once with progress, pause, cancel and retry. The hard part is that every file is a small long-running job that can fail halfway, and a 4 GB video on hotel Wi-Fi must survive a dropped connection and even a page reload.
- #16Design a tag (multi-select) inputA text box that collects many values as removable chips: free-form tags, picks from a list, or email recipients. The hard parts are the value model (trimming, case-insensitive duplicates, limits), the keys that commit and delete tags, pasting lists with bad items, suggestions, a keyboard and screen reader model that spans chips and a listbox, and plain form submission.
- #17Design a theme switcher with dark modeA Light, Dark and System control that shows the right theme from the very first paint on every page. Flipping colors is easy; the real work is the three-state choice and where it lives, the tiny script that prevents a white flash, semantic color tokens, images and charts that follow along, contrast in both themes, tabs that stay in sync, and stepping aside for the operating system's forced colors.
- #18Design a loading skeleton systemThe loading placeholders of a design system: grey shapes that stand in for content while it loads. Drawing a grey box is easy; the real work is deciding when to show nothing, a skeleton, a spinner or the old content, making the shapes match the real layout so nothing jumps, giving teams a small API that stays in sync with the real components, animating many skeletons cheaply and in step, keeping them quiet for screen readers, fitting them into streaming server rendering, and making sure every skeleton ends in content, an empty state or an error.
- #19Design a throttled progress bar queueClicking Add appends a progress bar, but only K bars may run at once and the rest wait in line. The toy hides a real component: the upload tray in Google Drive, a batch image resizer, a bulk email sender. The hard parts are a state model the scheduler and the UI agree on, a scheduler that keeps exactly K slots busy through pause, cancel, retry and live changes to K, progress that animates smoothly and honestly even in a background tab, and hundreds of rows that render without jank.
- #20Design a countdown timerA reusable countdown for sales that end, auctions, launches, resend buttons, exams and focus timers. Showing a number that goes down looks trivial, but the hard parts are hidden: timers that drift and get throttled in background tabs, device clocks that are wrong, deadlines that move, an expiry that must fire exactly once, server rendering that is stale on arrival, and a display that a screen reader can live with.
- #21Design a data tableA reusable data table for a design system that sorts, filters, pages, selects, resizes, and edits rows. It looks like an HTML table with a few buttons, but the hard parts are where the data lives (browser or server), keeping 100,000 rows smooth, a column API that 30 teams can share, and a keyboard and screen reader story that still works when most rows aren't in the DOM.
- #22Design a virtualized listA reusable list that can hold 100,000 rows but only keeps the few dozen near the screen in the page. The idea fits in one line; the hard parts are the offset math, rows whose height is unknown until they render, keeping the reader's place while sizes change and older items load above, fast flings, browser height limits, and what screen readers, keyboards, and find-in-page lose.
- #23Design a file-explorer tree viewA reusable folder tree like the explorer in VS Code or the sidebar in Google Drive. Showing nested folders is easy; the hard parts are a flat data shape that makes moves and lazy loading cheap, loading children on expand with per-folder errors, the full tree keyboard and screen reader pattern, multi-select in tree order, virtualizing 100,000 rows, drag to move with rollback, inline rename, filtering, and live updates that don't lose your place.
- #24Design a command paletteA keyboard-first box, opened with Cmd+K or Ctrl+K, that finds and runs any action or item in the app. The hard parts are a shortcut that doesn't fight the browser, a registry that features add commands to without one giant import, fuzzy matching that ranks the right thing first, nested pages, server results that race the user's typing, and a combobox that works with a screen reader.
- #25Design a calendar week viewA reusable day, 3-day and week time grid that product teams embed, like FullCalendar's time grid or the week view of Google Calendar. Drawing boxes on a grid is easy; the hard parts are an API built on instants with async edit callbacks, mapping time to pixels per day column in a chosen time zone (including 23 and 25 hour days), splitting events at midnight, packing all-day bars, drag to create, move and resize that stays smooth and rolls back on failure, keyboard and screen reader access, localization, and server rendering without knowing the user's time zone.
- #26Design a Kanban boardA reusable board component where cards sit in columns and move by drag and drop, keyboard, or menu. The hard parts are drag mechanics that stay smooth with thousands of cards, an order that survives many people moving cards at once, and a board that works with touch, keyboard, and screen readers.
- #27Design a drag-and-drop reorderable listA reusable sortable list where people change the order of items by dragging, by keyboard, or with move buttons. The hard parts are finding the right drop position with items of different heights, moving the other items smoothly without fighting the DOM, and saving the new order safely.
- #28Design a combobox for 100,000 optionsA searchable select over a huge list, like every city on Earth or every person in a 50,000-person company. The hard parts are what breaks at that size: rendering only the visible rows while keeping ARIA correct, a keyboard model that jumps through 100,000 rows, filtering every keystroke in a worker without lag, shipping and caching the data, grouped rows, and remembering selections the list no longer shows.
- #29Design a rich text editorA reusable editing component where people write formatted text with headings, lists, links, mentions, and images. The hard parts are keeping a clean document model separate from the messy browser DOM, handling every kind of input (IME, mobile keyboards, paste) without losing text, and staying fast on every keystroke.
- #30Design an @-mention inputA message box where typing @ opens a list of people, and picking one inserts a mention that notifies them. The hard parts are knowing when a mention starts, placing the popup at the caret, keeping mentions as tokens with ids instead of plain text, deleting them as one piece, and working with mobile keyboards and screen readers.
- #31Design a markdown editor with live previewA text box where people write markdown and see it rendered as they type. The hard parts are smart editing that keeps native undo, rendering fast enough for long documents, never letting user HTML run as script, keeping the source and the preview scrolled together, pasting images, and saving drafts that survive a crash.
- #32Design an embeddable code editorThe editor box that playgrounds, online judges, and code review tools embed. Showing colored text is the easy part; the hard parts are catching typed text from every keyboard and input method without letting the browser corrupt the document, storing a 10 MB file so an edit costs microseconds, drawing only the 40 lines on screen, re-highlighting after each keystroke without blocking it, and staying usable with a screen reader.
- #33Design a drag-and-drop form builderAn editor where people who don't write code build forms by dragging fields onto a canvas, plus a renderer that shows those forms to thousands of respondents: the hard parts are the form definition as versioned data, one field registry shared by editor and renderer, validation and show/hide logic expressed as data instead of code, and publishing new versions without breaking the answers already collected.
- #34Design a multi-step form wizardA reusable wizard for long forms like checkout, onboarding, insurance quotes and visa applications: steps that appear or vanish based on earlier answers, validation at the field, step and server level, a URL per step, drafts that survive a closed tab, and a final submit that happens exactly once.
- #35Design a color pickerA design-system color picker: a saturation and brightness square, hue and alpha sliders, a hex field, an eyedropper, swatches and a live contrast check. The hard part is color itself: picking the model the user edits, keeping hue stable when a color turns gray, converting and rounding without drift, handling colors outside the screen's gamut, and making a two-dimensional drag area work with a keyboard and a screen reader.
- #36Design an avatar image cropperThe "crop your new profile photo" dialog from GitHub, Slack, LinkedIn and Google accounts: show a photo under a round or square frame, let people drag, zoom and rotate it with mouse, touch and keyboard, then cut out a small square image. The hard parts are the coordinate math between screen pixels and photo pixels, gestures that feel native on every device, and a 48 MP phone photo that needs about 195 MB of memory once decoded.
- #37Design a signature padThe box where you sign with a finger, pen, or mouse in DocuSign or on a courier's phone. It looks like a canvas with a Clear button, but the hard parts are hidden: one input path for mouse, pen and touch, a page that scrolls everywhere except the pad, smooth strokes that look like ink, a crisp drawing on every screen that survives a resize, undo, a check that rejects a stray dot, compact export, and a typed alternative for people who cannot draw.
- #38Design an emoji and GIF pickerA popup that lets people find and insert one of nearly 4,000 emoji or a GIF from a search service. The hard parts are the emoji data (sequences, skin tones, keywords per language, hundreds of KB), emoji the device can't draw, a grid of thousands of cells that stays fast, local search, recents, a full keyboard and screen reader model, inserting at the caret, and a GIF tab that talks to a provider like GIPHY.
- #39Design a video playerA reusable video player component with its own controls on top of the browser's video element: play, seek with preview frames, volume, speed, captions, quality, fullscreen, and picture-in-picture. The hard parts are turning a noisy stream of media events into one honest player state, building a seek bar and controls that work with a mouse, a finger, a keyboard, and a screen reader, and playing adaptive streams that survive bad networks.
- #40Design a podcast audio playerA web podcast player that keeps playing while you browse, shows up on the lock screen, remembers where you stopped on every device, plays faster without chipmunk voices, trims silence, jumps between chapters and works offline. Playing a file is one line; the hard parts are the long life of one audio element, the operating system around it, and a position that must never be lost.
- #41Design an image lightbox with zoomThe full-screen photo viewer that opens when you tap a thumbnail in Google Photos, an Airbnb listing or an Amazon product page: grow the photo out of its thumbnail, load a sharp version without a blank flash, let people zoom to the pixel and pan, swipe to the next photo or down to close, and keep Back, focus and memory under control.
- #42Design an Instagram-style stories viewerA reusable full-screen viewer that plays a tray of users' short photo and video stories in order, with segmented progress bars, tap zones, hold to pause, and swipes between users. The hard parts are a clock that pauses and resumes exactly for many reasons at once, telling taps from holds from swipes, preloading just enough media, and counting a story as seen honestly.
- #43Design a podcast player with a synced transcriptA transcript panel next to a podcast player that highlights the word being spoken, scrolls along without fighting the reader, seeks when you click a line, finds words in a 3 hour episode and shares a quote at its exact second. Showing text is easy; the hard parts are keeping 30,000 words in sync with audio without re-rendering them, and an auto-scroll that knows when to stop.
- #44Design a PDF viewerA reusable PDF viewer component that opens a 2-page invoice or a 900-page manual with the same speed: page 1 on screen before the file finishes downloading, smooth scrolling and zoom, search, text selection, thumbnails, annotations, and forms. The hard parts are drawing pages yourself without running out of memory, loading only the bytes you need, and mapping between PDF coordinates and screen pixels so highlights stay put under zoom and rotation.
- #45Design a news feedAn endless, server-ranked list of posts with photos, video, likes, comments, and a composer, updating live while people read. The hard parts are paging a list that changes under you, staying smooth after hundreds of posts, keeping one copy of each post across screens, instant likes that stay correct, and new posts that never move what the user is reading.
- #46Design a nested comments threadA comment section where people reply to replies, as on Reddit or Hacker News. It looks like a list with indentation, but the hard parts are turning a flat list of comments into a tree fast, loading a tree that may hold 20,000 comments a branch at a time, sorting it fairly, posting replies instantly before the server answers, and keeping the page still while new replies arrive.
- #47Design a notification centerThe bell icon with an unread badge and a panel of notifications, as in GitHub, LinkedIn, Facebook and Jira. Drawing a list is easy; the hard parts are a badge that stays correct across tabs and devices, live delivery that survives reconnects, "seen" versus "read", grouped items like "Ana and 4 others liked your post", mark all as read without a race, and push notifications that don't duplicate the in-app ones.
- #48Design a like button for millions of usersThe heart under every post: one tap flips it, the count moves by one, and it must feel instant for millions of people at once. The hard parts are hidden: sending the final state instead of the tap so retries and double taps are safe, an optimistic flip that can roll back, rapid like and unlike taps that must end on the right state, counts that are only eventually correct, and the same post showing in many places that must all agree.
- #49Design a search results pageThe shop page you land on after typing "running shoes": a query, faceted filters, sorting, a results grid and pages. The hard parts are one search state that lives in the URL, facet counts that don't make options vanish, one cancellable request per change, a grid that never blanks or jumps, honest zero results, and pages Google can index without crawling a billion filter combinations.
- #50Design live comments for a sports streamThe live chat rail next to a sports stream, where thousands of viewers post at once and a goal can push the rate to thousands of messages per second. The hard parts are showing a readable stream instead of a blur, rendering it without hurting the video, keeping the scroll where the reader wants it, sending with instant feedback under slow mode and moderation, and not spoiling a goal the viewer has not seen yet.
- #51Design a customer support chat widgetThe chat bubble in the corner of other companies' websites. The hard parts are loading it without hurting the host page, knowing who the visitor is without letting anyone impersonate a customer, keeping the conversation alive while the visitor clicks through pages and tabs, handing over from a bot to a human, and getting attention without becoming the most annoying thing on the page.
- #52Design an embeddable poll widgetA small poll that news sites and blogs paste into their pages: a question, a few options, a vote, and live results. It looks like a form with radio buttons, but the hard parts are running safely inside someone else's page, keeping it tiny, allowing one vote per person without tracking anyone, showing results that update live and add up to 100%, and surviving a traffic spike when a big site embeds it.
- #53Design a recently viewed products featureThe row of products a shopper looked at lately, like Amazon's browsing history or Flipkart's Recently viewed. Showing a list is easy; the real work is deciding what counts as a view, where the list lives for guests and signed-in users, merging the two on login, keeping tabs in step, refreshing stale prices, and giving people control over their own history.
- #54Design product ratings and reviewsThe reviews section of a product page and the form for writing one: a rating summary with a histogram, a sortable and filterable list, helpful votes, photos, and seller replies. It looks like a list with stars, but the hard parts are honest numbers (averages that don't lie with 2 reviews), a ranking that surfaces useful reviews, state that lives in the URL, search engines reading it, and trust rules that now carry legal weight.
- #55Design an e-commerce cart and checkoutA cart that works for guests and signed-in shoppers, stays the same across tabs and devices, and feeds a multi-step checkout that takes payment exactly once. The hard parts are deciding who owns the cart, merging carts at sign-in, quantity changes that race each other, prices and stock that change under the shopper, and a payment step that must never charge twice.
- #56Design a checkout flowThe checkout of an online store: address, shipping, payment, review, and place order, for guests and signed-in shoppers, with express wallets. The hard parts are a total that changes with every address and code, card data that must never touch your servers, and a place-order request that must charge exactly once even when the network drops at the worst moment.
- #57Design a secure payment formThe card-entry component a payment provider ships to merchants, like Stripe's Payment Element or Braintree Hosted Fields. The hard parts are keeping card numbers out of the merchant's page while still letting the merchant style it, reacting to every keystroke with formatting and brand detection across a frame boundary, and confirming a payment exactly once when 3-D Secure, wallets, and flaky networks get in the way.
- #58Design sign up and sign inThe front door of a SaaS app: sign up, sign in, sign out, password reset, MFA, social sign-in and passkeys, where the hard part is keeping the session safe from XSS and CSRF, never telling an attacker which accounts exist, and still letting real people in quickly on any device.
- #59Design a product tourAn in-app product tour and onboarding checklist: welcome modals, step-by-step tips anchored to real UI, a spotlight that dims everything but one button, beacons, and a checklist that completes when people do the real thing. Drawing a bubble is easy; the hard parts are steps defined as data, anchoring to elements that load late or never appear, a spotlight that lets the right clicks through, progress that survives reloads and devices, rules so tours never stack or nag, measuring whether a tour helps at all, and doing it without hurting load speed or accessibility.
- #60Design undo and redoOne undo and redo system that a canvas editor, a kanban board, and a form builder can all reuse. The hard parts are choosing commands over snapshots, deciding what one step is, keeping memory bounded, staying correct while every edit autosaves, and undoing only your own changes while teammates edit the same document.
- #61Design a CSV import with column mappingThe "Import contacts from CSV or Excel" flow: read a file the user exported from somewhere else, match its columns to your fields, check every cell, and create or update thousands of records. The hard parts are parsing messy real-world files without freezing the tab, guessing the mapping well, showing errors people can fix, and sending the rows so that a failure halfway through never creates duplicates.
- #62Design report exportThe "Export" button of an analytics or admin product: turn what the user sees on screen into a CSV, Excel, PDF or JSON file and get it onto their disk. The hard parts are choosing between building the file in the browser and running a server job, keeping the file faithful to the screen and to permissions, and writing files that Excel opens correctly and safely, from 50 rows to 5 million.
- #63Design permission-based UIThe frontend side of authorization in a B2B app: what each user sees and can do depends on their role, their team, the resource, and the customer's plan. Showing the right buttons is the easy part; the real work is never trusting the client, choosing what the browser is told, deciding between hiding, disabling, and explaining, and keeping the UI honest when permissions change while the page is open.
- #64Design a client-side analytics SDKA small script that any website embeds to send product events to a collector, like Segment's analytics.js or Amplitude. The hard parts are a public API that works before the script loads, loading without hurting the host page, identity and sessions, a durable event queue with batching and retries, delivery when the tab closes, sampling, consent, and privacy.
- #65Design a feature flag SDKA small client library that tells a React app which features are on for this user. Reading a boolean is easy; the real work is where flags get evaluated, showing the right value on the first frame, keeping each user in the same rollout bucket, pushing kill switches live, logging exposures that experiments can trust, and never crashing the app.
- #66Design an A/B testing system for the frontendThe frontend of an experimentation platform: the screens where teams set up experiments, the code that puts each visitor in a variant and shows it without flicker, the exposure events that say who really saw what, and the results page people use to decide. The hard part is not showing two versions; it is making sure the numbers at the end can be trusted.
- #67Design a frontend logging and error SDKThe browser SDK of an error tracker like Sentry or Datadog: it catches every kind of failure on the page, turns minified stack traces from different browsers into one readable issue per bug, records what happened before the crash, strips personal data, and keeps the noise down without ever breaking the page it watches.
- #68Design an internationalization systemThe i18n platform behind a product that ships in 30+ languages: the API app developers write against, the pipeline that carries strings to translators and back without blocking releases, and the runtime that loads only the right catalog and renders plurals, genders, dates and right-to-left text correctly. The hard part is the system around the strings: ids that survive edits, a message format translators can work with, catalogs that stay small, and checks that stop a broken translation before users see it.
- #69Design an embeddable third-party widgetA widget other companies add to their sites with one script tag, like a support chat bubble or a payment form. The hard parts are a tiny loader that never blocks the host page, isolating our CSS and JavaScript from a page we don't control (and the page from us), a safe message protocol across the iframe boundary, versioned rollouts with a kill switch, a small performance budget, blocked third-party cookies, and accessibility across frames.
- #70Design a cookie consent managerThe consent banner and preferences center that decide which cookies, scripts, and embeds may run, like OneTrust, Cookiebot, or Klaro. The hard parts are blocking non-essential scripts before the user chooses, a fair banner that regulators accept, storing proof of the choice, rules that differ by region, and doing all of it without hurting page speed or accessibility.
- #71Design state sync across browser tabsPeople keep the same web app open in five tabs at once. The hard parts are deciding which state must cross the tab boundary and how fast, picking a transport between tabs, electing one tab to own the WebSocket and the timers, refreshing a token exactly once for everyone, keeping tabs consistent when messages arrive late or never, and not breaking when two tabs run different versions of the app.
- #72Design a client-side rate-limited action queueA browser app must send many actions to an API that allows only so many requests per second or per hour. The hard parts are pacing requests under two limits at once, learning the real limit from the server's 429 replies and headers, retrying without doubling writes, keeping user actions ahead of background work, and keeping the queue alive across reloads and tabs without ever dropping an action silently.
- #73Design a chat appThe web client of a chat app with one-to-one and group chats, receipts, presence, typing, media, and offline sending. The hard parts are a live two-way connection that dies silently, sends that show at once but are never lost or doubled, one shared order across devices, years of history you can open anywhere, and recovering cleanly after sleep, network changes, and deploys.
- #74Design a real-time leaderboardA ranked list of players that changes while you watch: a top 100, your own rank among millions, daily and all-time boards, friends and country scopes. The hard parts are computing ranks and ties on the server, showing the top and the rows around you, turning a stream of score changes into calm, readable updates, animating rows that move without stealing the scroll, pinning your own row, and staying honest when the data is stale or frozen.
- #75Design a live stock price tickerLive quotes on a watchlist and a symbol page: rows of prices that change many times per second, flash green or red on each move, and feed a live chart. The hard parts are market data itself (quotes, trades, sequence numbers, snapshots, market sessions, delayed feeds), one socket that follows what is on screen, rendering hundreds of updates per second without re-rendering the table, flashes that stay safe, numbers that don't jitter, and honest labels when data is stale, delayed or the market is closed.
- #76Design an LLM chat interface with streaming answersThe chat screen of an AI assistant, where a question goes in and the answer streams back word by word as formatted markdown. The hard parts are reading a stream over a plain POST, stopping and resuming it, rendering half-finished markdown fast and safely, keeping the scroll where the reader wants it, and turning edits and regenerations into a tree of versions.
- #77Design a live cricket score page for 50 million fansA live cricket score page that tens of millions of phones open in the same minute: one scorer writes each ball, everyone reads the same bytes. The hard parts are the load shape (a herd at the toss, every wicket and the last over), choosing between CDN-cached polling and open streams with real numbers, a ball-by-ball event log with sequence numbers and corrections, a client that never shows the score going backwards by mistake, a server-rendered page with small live islands, and cheap phones on flaky 3G.
- #78Design a multiplayer trivia gameA live quiz where a host runs rounds and thousands of players answer on their phones at the same moment. The hard part is not the quiz screen: it is one synchronized game loop driven by the server, the same deadline for every player whatever their clock and latency, fair speed scoring, fan-out to 100,000 sockets, and players who reload or lose Wi-Fi in the middle of a question.
- #79Design Twitter (X)The whole web client of a real-time social network: a timeline, post pages with reply trees, a composer, search, notifications, and public pages that share well. The hard parts are one post shown in many shapes, routes that keep the timeline alive under modals, character counting that matches the server, server-rendered pages for crawlers and preview bots, live counts that don't flood the server, and all of it fast on a cheap phone in any language.
- #80Design InstagramA photo sharing web app: an image-first feed, stories with a full-screen viewer, posting photos from the browser, likes, comments, and profiles, where the hard part is moving a lot of media fast on phones without layout shift, wasted data, or lost uploads.
- #81Design RedditThe web client of a network of communities: subreddit pages with their own look, rules, and flairs, ranked listings with sorts like hot and top, three-state voting at huge scale, a composer for many post types, safe user markdown, and post pages that search engines send millions of signed-out readers to. The hard parts are letting thousands of communities theme their pages without breaking readability, paging through rankings that move while you read, and serving one post URL to a crawler, a guest, a member, and a moderator.
- #82Design PinterestA visual discovery app: an endless grid of images in columns of different heights, a pin detail that opens over the grid, related pins, and saving to boards. The hard parts are a masonry layout that never jumps, virtualizing a grid where every item has its own height, loading hundreds of images in the right order, and a detail view that is a modal and a real page at the same time.
- #83Design LinkedInThe web client of a professional network: public profiles that search engines index and guests open from a link, rich profiles that members edit section by section, a graph of connections with privacy rules, and messaging, notifications, and jobs in one app shell. The hard parts are serving one URL to two very different audiences, never sending a viewer data they may not see, and editing many sections safely.
- #84Design a TikTok-style vertical video feedAn endless feed of short vertical videos where exactly one fills the screen and plays at a time, with likes, comments, and shares on top. The hard parts are deciding which video is active during fast flicks, starting each video in well under a second without wasting data, staying inside the phone's memory and decoder limits, and following the browser's autoplay rules.
- #85Design Stack OverflowThe web client of a programming Q&A site: question pages that search engines send millions of signed-out readers to, plus asking, answering, voting, editing, and moderation for signed-in members. The hard parts are serving one cached page to every anonymous reader while still showing each member their own votes and unlocked actions, an ask flow that catches duplicates before they are posted, and rules that depend on the viewer's reputation.
- #86Design DiscordThe web and desktop client of a community chat app like Discord: one person in dozens of servers, some with hundreds of thousands of members, text and voice channels side by side. The hard parts are one live connection that carries every server without drowning the client, a member list that shows a slice of a huge server and keeps it live, permissions computed on the client to shape the UI, voice that keeps running while you read, and rich messages full of custom emoji, embeds, and reactions.
- #87Design a blogging platform like MediumA long-form reading and publishing platform where most visitors arrive from search or social links to read one article, a few become members, and a smaller group writes. The hard parts are serving the article page from the edge while still showing each reader their own claps, highlights, and paywall meter, keeping a 3,000-word page fast and readable, metering free reads in a way that can't be bypassed but still lets search engines index the text, anchoring highlights to text that authors later edit, and a writing flow with autosave, previews, scheduling, and email delivery.
- #88Design YouTubeA video site with a fast watch page, a custom player that adapts quality to the network, a mini-player that keeps playing across pages, a home grid and recommendations, comments, and resumable uploads. The hard parts are a quick first frame, playback without stalls on any network, one player that outlives every page, and gigabyte uploads that survive drops.
- #89Design NetflixA video streaming client with a browse page of many personalized rows of artwork, delayed trailer previews on hover and focus, a TV interface driven by a remote, and a protected player that adapts quality to the network and remembers where you stopped. The hard parts are a browse page that stays smooth with thousands of images, focus that moves sensibly with four arrow keys, and playback that starts fast and never stalls.
- #90Design the Spotify web playerA music web app where one player keeps playing while you browse, search, and edit playlists, with a queue you can reorder, lock screen controls, and a remote control for your other devices. The hard parts are a player that survives every page change, track changes with no silence between songs, a queue with honest shuffle and repeat, and one playback state shared by several devices.
- #91Design an e-commerce site like AmazonThe storefront of a huge online marketplace: home, search results with filters, product pages, cart, and checkout. The hard parts are picking a rendering strategy per page type, keeping filters in the URL, a product page that paints fast and handles variants, prices and stock that change under the shopper, a checkout that never charges twice, and many sellers competing for the same product.
- #92Design AirbnbA travel booking web app: search stays on a list and a map that move together, pick dates and guests, read a listing, and book it. The hard parts are keeping the list, the map, and the URL in sync while the user pans, drawing hundreds of price markers fast, an accessible date range picker that never shifts a day, and a price that stays honest from the search card to the payment.
- #93Design a flight booking siteA site where people search flights from many airlines and agencies, compare and filter thousands of results, pick a flight and seats, and pay. The hard parts are a search that streams in over 5 to 30 seconds, fast filters over thousands of itineraries, prices that are cached quotes and can change on select, a multi-step booking racing a fare hold, and a booking request that must never charge twice.
- #94Design a seat selection map for eventsAn interactive map of a stadium or theater where fans pick exact seats from 5,000 to 80,000, while thousands of other buyers grab seats at the same moment. The hard parts are drawing and hit-testing tens of thousands of seats at 60 frames per second, keeping availability live during an on-sale rush, holding seats on the server with a timer, and giving keyboard and screen reader users an equal way to choose.
- #95Design a food delivery appThe customer web app of a service like DoorDash, Uber Eats, Deliveroo, Swiggy, or Zomato: set a delivery address, browse nearby restaurants, build a cart from a menu with item options, place the order, and follow it until it arrives. The hard parts are an address that every other piece of data depends on, menus and prices that change under the customer, a cart the server prices, an order that must be placed exactly once, and a live status that stays calm even when events arrive late or twice.
- #96Design a grocery delivery slot pickerThe grid of days and delivery windows where a grocery shopper books a van to their door, each window with limited capacity that sells out in minutes before a holiday. The hard parts are a slot model that depends on the address and the basket, availability that stays seconds fresh while thousands of people want the same Saturday, a long hold that belongs to the basket, local time and daylight saving days, and a grid that works with a keyboard and a screen reader.
- #97Design Uber's rider web appThe mobile web app a rider uses to book a car: pick a pickup point and a destination, compare products and upfront fares, request, watch the driver arrive on a live map, ride, pay, and rate. The hard parts are a trip that is a server-owned state machine the client must mirror through reloads and lost connections, a moving car that looks smooth even though updates arrive every few seconds, a request that can never book twice, and all of it fast on a low-end phone on a weak network.
- #98Design a collaborative document editor like Google DocsA rich text editor where many people type into the same document at once, each seeing their own keystrokes instantly and everyone else's within a fraction of a second. The hard parts are merging edits made at the same moment without losing anyone's work, keeping cursors, comments, and undo correct while the text moves, and catching up after hours offline.
- #99Design Google SheetsA collaborative spreadsheet in the browser: a grid that scrolls smoothly over millions of cells, a selection and editing model that feels like a desktop app, a formula engine that recalculates only what changed, and many people editing the same sheet at once.
- #100Design a collaborative design tool like FigmaA browser app where designers draw frames, shapes, and text on an endless canvas, and several people edit the same file at once. The hard parts are drawing tens of thousands of layers at 60 frames per second, finding what is under the pointer in under a millisecond, and merging edits from many people without a central lock.
- #101Design a whiteboard like ExcalidrawA browser whiteboard where people sketch hand-drawn shapes, arrows, and text on an endless canvas, alone or together in a live room. The hard parts are a scene model simple enough to merge element by element, drawing thousands of rough shapes at 60 frames per second on Canvas 2D, and end-to-end encrypted collaboration where the server never sees the drawing.
- #102Design NotionA web app where every paragraph, heading, image, and page is a block in one big tree, edited by many people at once, with databases built from the same blocks. The hard parts are a data model flexible enough for all of it, editing and dragging blocks without breaking the tree, merging concurrent edits, and loading huge pages fast, online and offline.
- #103Design GmailThe web client of an email service like Gmail or Outlook: an inbox of thousands of threads, conversations, compose with drafts and undo send, search, and offline mode. The hard parts are a fast list you can select and change in bulk, showing untrusted email HTML safely, drafts that never lose a word, and a local mailbox that stays in sync with the server.
- #104Design Google CalendarA calendar web app with day, week, month, schedule and year views, many calendars, shared events and reminders. Boxes on a grid look easy; the hard parts are time zones and recurring events, laying out overlapping events, fetching only the visible range and keeping it fresh, and dragging events with snapping and safe rollback.
- #105Design Trello or JiraA project tracker where the same issues show up as a board, a backlog, a table, a timeline, and a personal inbox. The hard parts are keeping every view in sync from one issue cache, rendering fields and workflows that each project defines for itself, a query language that runs on the server, and staying fast with hundreds of thousands of issues.
- #106Design Google DriveThe web app at drive.google.com (and Dropbox on the web): browse folders that hold thousands of files, select and drag them around, upload and download in bulk, share with exact roles, and see changes made on other devices. The hard part is that the client holds a live, partial copy of a huge tree of files whose permissions, locations and contents change under it, and every click must still feel like a desktop file manager.
- #107Design SlackThe web and desktop client of a team chat app like Slack: many workspaces, hundreds of channels, threads, reactions, files, and search, open all day. The hard parts are a client store that starts instantly and stays correct through reconnects, unread state that matches what the user really saw, a message list that scrolls through years of history, and channels with thousands of members.
- #108Design an online code playground like CodePenA browser playground where people write HTML, CSS, and JavaScript in three editors and see the result run live beside them, then save, fork, share, and embed it. The hard parts are running strangers' code without letting it touch the app or its users, turning keystrokes into a fresh preview fast without freezing anything, catching infinite loops, and piping the preview's console and errors back to the editor.
- #109Design an online judge like LeetCodeA site where people read a coding problem, write a solution in one of many languages, run it on examples, and submit it against hidden tests, alone or in a timed contest. The hard parts are deciding where code runs, keeping hidden tests secret, showing a submission's progress live without hammering the server, keeping drafts safe, and surviving the traffic spike when a contest starts.
- #110Design a code review diff viewerThe "Files changed" page of a pull request: every changed file as a diff, inline comment threads anchored to lines, a file tree, and a review you build up in drafts and submit at once. The hard parts are showing a 1,000-file, 100,000-line change without freezing the tab, and keeping each comment attached to the right line while new commits keep moving the code under it.
- #111Design a web-based terminalAn interactive shell in a browser tab, connected to a real process on a server. Showing text is the easy part; the hard parts are modelling a grid of cells with a cursor and two screen buffers, parsing a byte stream of escape sequences that arrives in random chunks, drawing 10,000 cells at 60 frames per second, turning key presses into the bytes a shell expects, and keeping the tab responsive when a command prints 100 MB.
- #112Design an analytics dashboardBuild a dashboard of 20 or more charts and tables over time series data, with global filters, date ranges, drill-down, and live updates, where the hard part is fetching and drawing a lot of data fast without one slow or broken widget ruining the page.
- #113Design an admin CMSAn internal admin or headless CMS where editors list, create and edit entries of many content types: screens generated from schemas, server-driven list views, large forms with validation, drafts and scheduled publishing, two editors on one entry, a media library, and permissions down to single fields.
- #114Design an IoT dashboard for thousands of sensorsAn operator console for a factory, a building or a fleet: tens of thousands of sensors report every few seconds, and the browser must show live charts, fleet health and alarms without ever receiving the raw firehose. The hard parts are server-side aggregation and screen-driven subscriptions, pixel-aware downsampling that keeps spikes and gaps, live charts on canvas with ring buffers, honest handling of stale, late and missing data, and alarms that do not flap or storm.
- #115Design a log viewer for millions of linesA log pane that opens a 2 million line build log or a live service tail without freezing the tab. Virtualizing the rows is the easy part; the hard parts are where the lines live in memory, following a fast stream without fighting the reader, searching text that was never rendered, regexes that can hang a thread, and copying, linking, and reading lines that don't exist in the page.
- #116Design a browser extensionA real product extension for Chrome, Edge, Firefox, and Safari built on Manifest V3, like a highlighter, a password manager, or a writing assistant. The hard parts are a background service worker that the browser kills when idle, content scripts that run on every page you don't control, messaging between short-lived contexts, permissions that users have to trust, UI injected safely into any website, storage and auth across contexts, and shipping through store review to several browsers.
- #117Design a customer support ticket dashboardThe agent workspace of a help desk: live queues of tickets, a ticket view with the whole conversation, and a keyboard-first workflow for agents who handle a hundred tickets a day. The hard parts are a list that updates in real time without moving under the cursor, two agents never answering the same customer, SLA timers that pause outside business hours, a reply box that can never leak an internal note, and an app that stays fast after ten hours open.
- #118Design Google MapsThe web app at google.com/maps: a map of the whole planet you can pan, zoom, rotate, and tilt, with place search, a details panel, and driving directions with live traffic. The hard parts are turning a sphere into square tiles the browser can fetch and cache, drawing them at 60 frames per second while the user drags and pinches, showing thousands of markers without melting the page, and keeping the URL, the side panel, and the map in agreement.
- #119Design a collaborative pixel canvas like r/placeOne giant shared image that millions of people edit one pixel at a time, with a cooldown between placements. The hard parts are storing and shipping millions of pixels compactly, loading a snapshot and the live changes without gaps, drawing it all on one canvas at 60 frames per second, zooming to a single pixel on a phone, placing a pixel with honest feedback, and fanning every change out to millions of open tabs.
- #120Design a web photo editorA layered photo editor in the browser, like Photopea or Photoshop on the web: layers with masks and blend modes, adjustments that never destroy the original pixels, brushes that keep up with a pen, and 24 MP photos that need about 96 MB per layer. The hard parts are the document model, a GPU rendering pipeline with enough color precision, tiling so memory and texture limits hold, cheap undo for pixel edits, and saving and exporting without freezing the page.
- #121Design a browser-based music studioA music studio in a browser tab: tracks of recorded audio and MIDI notes on a timeline, a mixer with effects, recording from a microphone, a piano roll and an export to a file. Playing one sound is easy; the hard parts are timing that stays exact to the millisecond while the page is busy, a real-time audio thread you must never block, latency you have to measure and correct, and audio files that weigh tens of megabytes per minute.
- #122Design a no-code website builderA visual editor where people who don't write code build responsive marketing sites by dragging blocks onto a live page, styling them per screen size, and publishing to a real domain. The hard parts are keeping the page as a tree of data, editing a real page inside an iframe with overlays drawn on top, dropping blocks into flex and grid layouts, a class and breakpoint styling model, and compiling the result into fast static HTML and CSS.
- #123Design a video call web app like Google MeetThe web client of a video meeting product like Google Meet or Zoom: a pre-join screen, a grid of live video tiles, screen sharing, chat and reactions, all in the browser. The hard parts are sending and receiving many video streams through a media server without melting the network or the CPU, laying out and subscribing only to the tiles people can see, and keeping the call alive when the network gets worse.
- #124Design a Twitch-style live stream pageThe viewer page of a live streaming site like Twitch, YouTube Live or Kick: a live player, chat beside it, follow and subscribe buttons, and the channel page around it. The hard parts are keeping viewers a few seconds behind real life without stalling, handling a stream that starts, drops, reconnects and ends while people watch, and keeping a heavy page fast while chat, alerts and overlays update many times a second.
- #125Design a QR code event check-in appThe door-staff app of an event platform: staff point a phone at an attendee's ticket QR code and see a big green or red answer in under a second, even when the venue Wi-Fi is dead. The hard parts are a ticket payload that can be checked without a network, fast and reliable camera scanning in the browser, an attendee list stored on the phone before doors open, and catching the same ticket scanned at two doors.
- #126Design a micro-frontend shellAn application shell that composes frontends built and deployed by several teams into one product: it routes URLs to apps, loads each app from a runtime manifest, mounts and unmounts it, and owns the header, navigation, and login. The hard parts are deciding whether to split at all, picking a composition method, sharing one copy of React without version fights, keeping one broken app from taking down the page, and shipping each team's code on its own schedule without making the product slow or inconsistent.
- #127Design a design system for many teamsA company-wide design system that 24 product teams use across React, Angular, server-rendered pages and native apps. Drawing a button is easy; the real work is one token source that feeds every platform and brand, components that split behavior from looks, styles that product code can override on purpose, versions and codemods that move 70 repos forward, quality gates that catch visual and accessibility regressions, and the governance that makes teams want to adopt it.
- #128Design a long insurance application formAn online application for car, home, life or health insurance with 50 to 200 questions: a question graph that grows and shrinks with the answers and is versioned like a legal document, a live price that changes as you answer, prefilled data the customer must confirm, disclosures and consent that are recorded word for word, an audit trail of every answer, and agents who fill the form with the customer on the phone.
- #129Design an offline sync engineA reusable client-side sync layer where the local database drives the UI and changes sync in the background. The hard parts are the durable mutation queue, pulling deltas with a cursor, rebasing pending local work on top of server changes, resolving conflicts, partial sync, client schema migrations, and many tabs sharing one database.
- #130Design WikipediaThe reading and editing experience of an online encyclopedia that serves billions of page views a month, mostly to anonymous readers, many of them on slow networks and cheap phones. The hard parts are serving almost every read from an edge cache and purging it on edit, keeping the article page light enough for a 2G connection, a reading layout that works in hundreds of languages and both writing directions, and an editor that catches two people changing the same article without real-time collaboration.
- #131Design a plan to make a slow e-commerce site fastA quarter-long plan to make slow product pages fast: measure real users first, take one slow page apart metric by metric, rank the fixes by impact, effort and risk, prove the gain with an experiment, and build the guardrails that stop the site from getting slow again.
- #132Design a dropdown menuA design-system action menu: a button opens a short list of commands, and picking one runs it. Drawing the list is easy; the real work is choosing when a menu is the right pattern at all, the full keyboard contract with typeahead and focus return, submenus that survive a diagonal mouse move, positioning that stays on screen, press-drag-release pointer handling, and an API that one shared instance can serve on a 500-row table.
- #133Design Google PhotosThe web app for a personal library of 50,000 to 200,000 photos and videos: one timeline grid that keeps every photo's shape, a date rail that jumps ten years in one drag, selection across rows that were never loaded, and thousands of uploads landing at their capture date. The hard parts are the size math, a justified layout computed lazily per day, virtualizing sections whose heights are guesses, and keeping the scroll position still when the guesses get corrected.
- #134Design a browser video editorA video editor in a browser tab: import clips, trim, split and arrange them on tracks, add text and music, preview in real time and export an MP4. Drawing a timeline is easy; the hard parts are that video is far too big to decode ahead of time, that the frame under the playhead must be exact, that preview must keep up at 30 frames per second on an ordinary laptop, and that export has to encode thousands of frames without running out of memory.
- #135Design a stock trading appThe web trading terminal of a broker such as Zerodha Kite, Groww, Robinhood, Interactive Brokers or Binance: watchlists, live quotes, market depth, candlestick charts, placing and tracking orders, positions and P&L. The hard parts are a flood of market data at the open that must be cut down to what is on screen, an order book that must never silently drift, charts built from history plus live ticks, orders that must never be placed twice or shown as filled when they are not, and a UI that is honest about stale data, closed markets and halts.
- #136Design an online chess gameA live game of chess between two people in the browser, from one-minute bullet to long classical games, with spectators watching. The hard part is not drawing 64 squares: it is a server that owns the rules and the clocks, moves that feel instant while the network is slow, fair clocks for a player with 300 ms of lag, premoves, and a socket that drops in the middle of a bullet game.
- #137Design a writing assistant like GrammarlyUnderline spelling, grammar and style mistakes as people type in any text field on any website, show a card with fixes, and apply a fix in one click. The hard parts are drawing underlines over editors you don't own, keeping suggestions attached to text that keeps changing, applying fixes so the host editor notices, and keeping private text private.
- #138Design a gamified learning app like DuolingoA web app where learners take short lessons made of many exercise types, earn XP, keep a daily streak, compete in weekly leagues, and practise offline or out loud. The hard parts are a lesson engine that renders any lesson from data and never stalls, fair answer checking, streaks that respect the learner's local day and can't be faked, offline lessons that still count, and speaking exercises that degrade gracefully.
- #139Design a 3D product configuratorThe 3D viewer on a product page where shoppers spin a sneaker, sofa or car and change its parts and materials, like Nike By You, Tesla's configurator or Google's model-viewer. The hard parts are an asset pipeline that turns a 50 MB CAD export into a few megabytes of glTF, loading 3D without hurting the page, rendering only when something changes, a product schema with rules and prices, and AR and accessibility for a canvas that screen readers cannot see.
- #140Design an e-signature workflow like DocuSignA sender uploads a PDF, places signature and data fields for each signer, and sends it; signers open an emailed link, prove who they are, are guided through their required fields in the right order, and sign; everyone gets a sealed final PDF with a certificate of completion. The hard parts are the envelope and routing model, mapping fields between PDF points and screen pixels, a guided signing flow that works on a phone, and keeping the legally binding artifact and the audit trail on the server.
- #141Design a scheduling link like CalendlyA public booking page where a host shares one link and an invitee anywhere in the world picks a free time, and both get a calendar event with a video link. The hard parts are computing free times from weekly rules, connected calendars, buffers and limits on the server, showing them correctly across time zones and daylight saving changes, and booking a slot that someone else may have taken a second ago.
- #142Design an online exam platformA timed, high-stakes test in the browser: 100,000 candidates press Start at the same minute, often on weak mobile networks, and every answer must survive refreshes, crashes and dropped connections. The hard parts are the start-time rush, a clock the server owns, an answer log that never loses a click, a fair and accessible question screen, and integrity signals that inform humans instead of accusing candidates.
- #143Design a documentation site like MDNA documentation site with thousands of reference and guide pages in several versions and languages, written as Markdown in git, built into static HTML, and read mostly by developers who arrive from a search engine. The hard parts are building and deploying 10,000+ pages fast, navigation and links that never break, versions and translations side by side, search, and live code examples that do not slow the page down.
- #144Design an AI image generation studioThe web app of an image generator like Midjourney or Adobe Firefly: write a prompt, wait while a GPU job runs, get a grid of results, then vary, upscale, and edit them. The hard parts are modelling slow, costly server jobs on the client, showing honest progress, charging credits fairly, and keeping a growing tree of generations and a big gallery fast.