The key idea
A convincing design connects a user's goal to clear ownership, a workable data flow, and specific tradeoffs.
What are you actually designing?
Frontend system design explains how an interface's pieces cooperate. You decide what the browser renders, which information it keeps, how it communicates with services, and what happens when an interaction succeeds or fails. The answer is a set of justified decisions, rather than a collection of framework names.
An interview prompt is usually open-ended. Several designs can work; their suitability depends on the agreed requirements. Keep the discussion focused on the client experience and its service contracts. Explain backend behavior where the interface depends on it, without inventing an entire distributed platform.
Start with a person and a small boundary
Before drawing boxes, describe one user's job. For a neighborhood feed: a resident opens the feed, reads recent updates, and likes a post. Agree whether publishing, comments, moderation, and offline editing belong in the discussion. Writing these boundaries prevents an impressive diagram from solving the wrong problem.
- Name the user, primary action, and successful outcome.
- Ask about device, network, content size, and whether public pages must be discoverable.
- Identify one difficult constraint, such as a long feed on a low-memory phone.
- Record uncertain requirements as assumptions that the interviewer can correct.
Give every responsibility a clear owner
| Owner | Typical responsibility | Feed example |
|---|---|---|
| View | Render state and expose accessible controls | Post card, like button, loading feedback |
| Feature logic | Coordinate user actions and transitions | Mark a like as pending; reconcile the result |
| Data layer | Fetch, cache, and reconcile remote records | Load a feed page and update a post by ID |
| Server | Enforce permissions and authoritative business rules | Verify the user may like this post; return its current state |
Hiding a button is not authorization
The client can guide users, but requests remain untrusted. Permissions must be checked by the server on each operation. A disabled control improves the interface; it cannot protect another user's records.
Trace one interaction from click to confirmation
- 1
Intent
The user likes post 42. Capture the post ID and desired state.
- 2
Pending
Show immediate feedback. Decide whether to optimistically change the count or wait for confirmation.
- 3
Request
Send the desired liked state. A repeatable set-state operation is easier to retry safely than a blind toggle.
- 4
Reconcile
Use the server's response as authoritative. If rejected, restore or refetch the affected state and explain the failure.
Now stress the same path: the user clicks twice, leaves the page, or receives responses out of order. Explain how pending operations are identified and how older responses avoid overwriting newer intent. Optimistic updates need a conflict policy, especially when several writes overlap.
Separate state by ownership and lifetime
Remote data
Posts and confirmed likes belong to the server. A client cache needs keys, freshness rules, and invalidation after changes.
Local interaction
An open composer, focused control, or pending button belongs close to the UI that uses it.
URL state
Shareable filters, search terms, and selected routes should survive a refresh and browser Back where appropriate.
Persisted drafts
Unsaved writing may need recovery. Decide its lifetime, storage limit, and behavior when accounts change.
Prefer one canonical record over copies in several stores. Keep a selected post ID and derive its current details from the record collection. Derive visible counts and labels where possible so separate state fields cannot silently disagree.
Turn quality goals into observable behavior
| Area | A concrete design decision |
|---|---|
| Performance | Choose rendering per route. Server or static HTML can expose content early; client interactivity still needs a sensible JavaScript budget. |
| Accessibility | Use semantic controls, visible focus, keyboard access, and useful status announcements. Test the complete interaction. |
| Resilience | Keep usable content during a failed refresh; distinguish no results from a request failure; provide a bounded retry. |
| Security and privacy | Display untrusted text safely, enforce access on the server, and keep credentials and private data out of logs. |
| Testing and observability | Exercise slow responses, duplicate actions, and rejected writes. Record failures and timing without storing sensitive input. |
| Responsive and international UI | Check narrow screens, long translated labels, text resizing, date formats, and right-to-left layout where needed. |
Make your reasoning visible
Your diagram cannot communicate decisions you never explain. Use the discussion to show how each choice solves an agreed problem, and revise it openly when new information changes the constraints.
| Signal | What to show |
|---|---|
| Problem understanding | A confirmed user journey and an explicit scope. |
| Architecture | Responsibilities, ownership, and a complete interaction flow. |
| Technical depth | The mechanism behind your chosen rendering, data, or interaction approach. |
| Tradeoffs | Alternatives, their costs, and why one fits the constraints. |
| Product judgment | Usable loading, failure, and recovery behavior. |
| Collaboration | Clear explanations and changes in response to feedback. |
Check your design before adding more boxes
Pick any familiar interface and sketch its primary interaction. A useful first design fits on a page: scope, major modules, state ownership, one request and response, and two tradeoffs. Add detail only when it answers a real requirement or failure case.
- Can someone follow a user's action through your diagram without guessing?
- Which state is authoritative, and what happens when cached information becomes stale?
- Can a keyboard user complete the task on a slow connection?
- What would you measure to know whether your chosen optimization helped?
Sources & further reading
Original explanations and examples by FineFrontend, informed by the guide and primary references below.
- GreatFrontEnd: Introduction (opens in a new tab)
Background on the interview format and frontend scope. Examples and explanations here are original.
- GreatFrontEnd: Evaluation criteria (opens in a new tab)
Further reading on the signals a design discussion can demonstrate.
- React: Choosing the state structure (opens in a new tab)
State ownership, derived values, and avoiding duplication.
- web.dev: Rendering on the web (opens in a new tab)
Rendering approaches and their performance tradeoffs.
- OWASP: Authorization cheat sheet (opens in a new tab)
Server-side access checks.
- OWASP: DOM-based XSS prevention (opens in a new tab)
Safe handling of untrusted display content.