Frontend Handbook
Written

The design method

A repeatable way to run any frontend design prompt: clarify requirements, shape the architecture and data model, define the interface, go deep on the hard parts, and defend the trade-offs — with interactive references.

A frontend system-design prompt — "design a news feed", "design autocomplete" — is open-ended on purpose. The skill being tested isn't the feature; it's whether you can run the design: scope it, structure it, and defend your choices, out loud, in order. This page is the method the rest of the section's case studies all apply. It teaches a way of thinking, so its demos are interactive references, not server labs — and every worked example is one answer, not the answer.

01

A framework for any prompt

Run every prompt through the same ordered stages. The order matters: each stage's output feeds the next, and skipping ahead (naming components before you've scoped, say) is the most common way a design goes wrong.

  • Clarify requirements → architecture → data model → interface & data flow → deep dives → trade-offs. (A common shorthand is RADIO.)
  • Budget your time. Spend the first fifth scoping and the middle on architecture and interface; leave room to go deep on the one or two genuinely hard parts rather than covering everything shallowly.
  • Think aloud and drive. State assumptions, write down what's out of scope, and lead the discussion through the stages instead of waiting to be asked.
  • Step the framework through a sample product in the demo to see how each stage lands differently for a feed, a typeahead, a chat app or a design system.

Try it: step the framework through a product

Work the method on

01 · Clarify requirements

~15% of your time

Turn a vague prompt into a scoped problem before designing anything.

Example: clarify requirements for a news feed

Scroll, post, like/comment, media. Ask: how personalised, how fresh, which devices, read-heavy vs write-heavy?

What to produce

  • The core user flows that must work (functional)
  • The non-functional bar: performance, accessibility, offline, i18n, security, device/network
  • An explicit list of what's out of scope, and the assumptions behind it

Common mistakes

  • Designing before scoping
  • Treating it as backend scale rather than the client experience
  • Never writing down what you're not building
Stage 1 of 6

One worked example; another team might render a news feed entirely on the client, or rank it differently — the method is the constant, the answers aren't.

  • Do: Follow the stages in order, timebox them, and go deep where the problem is actually hard.

    Avoid: Jumping to components or libraries before requirements, or spreading equally thin across every stage.

Read more:GreatFrontEnd: system design playbook(opens in a new tab)web.dev: Learn(opens in a new tab)

02

Requirements and scoping

Scoping is where seniors separate from mids. Before any design, split what the product does (functional) from how well it must do it (non-functional), and say out loud what you are not building.

  • Functional requirements are the user-visible flows that must work. Keep the first pass small and prioritised — a working core beats a broad sketch.
  • Non-functional requirements — performance, accessibility, offline, internationalisation, security, device and network — usually decide the architecture more than the feature list does.
  • Scope cuts are requirements too. "Out of scope: real-time, admin, i18n" is a design decision; stating it shows judgement and buys time for the hard parts.
  • The same prompt is a different build under different constraints: an offline-first feed, an SEO-critical feed and a watch feed share almost no architecture.

Try it: scope a sample product

Scope this product

An infinite, personalised feed of posts with media and interactions.

Functional (what it does)

  • Scroll an endless feed
  • Create a post with text and media
  • Like and comment, with the count updating
  • Pull to refresh / load newer

Non-functional (how well)

Performance
Fast first screen; smooth 60fps scroll over thousands of items.
Accessibility
Keyboard and screen-reader support; new items announced politely.
Network
Works on flaky mobile; images degrade gracefully.
Freshness
How stale may the feed be — seconds, or minutes?

Ask first

  • How is the feed ranked, and on the client or the server?
  • How fresh must it be?
  • Which media types, and what sizes?
  • Mobile-first or desktop too?

The non-functional bar and the scope cuts shape the design as much as the feature list: the same news feed is a different build offline-first, or SEO-critical, or for a watch.

  • Do: Ask clarifying questions first, write functional and non-functional lists, and name explicit scope cuts.

    Avoid: Assuming the prompt's scale and audience, or treating accessibility and performance as afterthoughts.

Read more:web.dev: Core Web Vitals(opens in a new tab)MDN: Accessibility(opens in a new tab)

03

Trade-offs and non-functionals

Most of the design is a handful of recurring decisions. There is rarely a single right answer — the senior move is to name the options, tie each to the non-functional bar it serves, and say which you'd pick and why.

  • Rendering strategy (CSR / SSR / SSG / streaming) trades first paint, SEO and freshness against complexity and cost.
  • Data fetching & caching, pagination, and state location each have a small menu of options with clear forces picking between them.
  • Realtime transport (polling / SSE / WebSocket) follows from how live the data must be and what you can operate.
  • Every decision should trace back to a requirement: you choose cursor pagination because the feed shifts, not because it's fashionable. Explore each decision's options in the demo.

Try it: compare the options for a decision

A recurring decision

Where and when the HTML is produced shapes load, SEO and interactivity.

PerformanceSEOFreshness

  • CSR

    Ship a shell; the client renders everything.

    Wins
    Simple hosting; app-like after load.
    Costs
    Slow first paint; weak SEO; needs JS.

  • SSR

    Render HTML per request on the server.

    Wins
    Fast first paint; fresh; SEO-friendly.
    Costs
    Server cost; hydration; TTFB tied to data.

  • SSG

    Render HTML at build time.

    Wins
    Fastest, cacheable, cheap.
    Costs
    Stale until rebuilt; not for per-user data.

  • Streaming / RSC

    Stream server-rendered chunks, hydrate islands.

    Wins
    Fast perceived load; less client JS.
    Costs
    More complex; newer model.

There's no single winner — each option serves the performance, seo, freshness bar differently. The senior answer names the assumption and the alternative, not just a pick.

  • Do: Tie each choice to the requirement it serves, state your assumption, and name the alternative you'd switch to if it changed.

    Avoid: Declaring one option "best" with no context, or optimising something that isn't the bottleneck.

Read more:web.dev: Rendering on the web(opens in a new tab)GreatFrontEnd: system design playbook(opens in a new tab)

Next: the case-study pages apply this method to concrete prompts. The first, Design a news feed, picks up where this framework's worked example leaves off, followed by Design an autocomplete; a chat app and a design system follow.