Frontend System Design Answer Playbook
Purpose
This playbook gives a repeatable structure for frontend system design interviews and architecture reviews. It works for dashboards, funnels, design systems, offline apps, observability platforms, account portals, and GenUI copilots.
The 7-part answer
1. Clarify the product surface
Ask:
- who are the users?
- what are the critical journeys?
- what are the route/workflow boundaries?
- what is high risk: revenue, identity, compliance, accessibility, latency, data correctness?
- what scale matters: users, tenants, routes, teams, data volume, regions, devices?
2. Establish constraints
| Constraint | Examples |
|---|---|
| Product | conversion, retention, support, compliance |
| Runtime | mobile, slow networks, main thread, hydration, storage |
| Data | freshness, ownership, permissions, consistency |
| Interaction | loading, pending, empty, error, partial, offline |
| Quality | performance, accessibility, security, reliability |
| Team | ownership, release model, shared packages, migration |
3. Draw the system boundary
Use a diagram with:
- browser app
- route/rendering boundary
- BFF/API
- domain services
- design system
- observability
- feature flags
- third-party scripts
- auth/session
4. Decide rendering, data, and state
Produce:
- route rendering matrix
- data ownership and freshness table
- state placement table
- mutation lifecycle
- cache invalidation plan
5. Define module and platform boundaries
Explain:
- feature ownership
- shared packages
- design-system responsibilities
- import rules
- exception policy
- migration path
6. Define quality gates
Cover:
- Web Vitals and interaction budgets
- accessibility contracts
- browser security/privacy controls
- degraded states
- observability schema
- launch and rollback
7. Close with tradeoffs
Name:
- rejected alternatives
- what is reversible
- what is hard to change
- what you would pilot first
- what you would measure after launch
Answer skeleton
I would frame this as [product surface] for [users] whose critical journey is [journey].
The main risks are [risk list].
I would split the architecture into:
1. route/rendering strategy
2. data and mutation contracts
3. state ownership
4. module/design-system boundaries
5. quality gates and rollout
The key decision is [decision]. I reject [alternative] because [tradeoff].
I would verify it with [pre-release evidence] and [production signal].
Common diagrams
Route/data boundary
Quality gate flow
Scoring guide
| Score | Signal |
|---|---|
| Weak | lists tools, ignores constraints, no failure modes |
| Solid senior | makes reasonable route/data decisions and names tradeoffs |
| Staff-level | connects decisions to ownership, rollout, quality gates, and production signals |
| Architect-level | creates reusable decision criteria and operating model for teams |
Practice prompts
- Design an authenticated dashboard with saved filters and exports.
- Design a performance-critical lead funnel with experiments and attribution.
- Design a design-system platform for five product teams.
- Design an offline-first field app with conflict resolution.
- Design frontend observability for a multi-tenant SaaS product.
- Design a GenUI copilot with generated components and tool approvals.
Architecture drill format
Use this after every practice prompt:
| Step | Evidence |
|---|---|
| Scenario | state users, route/workflow, constraints, and risk class |
| Decision prompt | name the irreversible or high-cost choice |
| Expected architect answer | clarify outcome, map constraints, compare options, choose, verify |
| Common weak answers | list tool-first, happy-path-only, or no-ownership answers |
| Artifact | diagram, matrix, ADR, scorecard, or review packet |
Expected architect-level answer
A strong answer should:
- start from user outcome and risk, not framework choice
- draw the system boundary before naming libraries
- separate URL, server, local UI, form, and global shell state
- define route-specific rendering strategy
- name performance, accessibility, security, privacy, reliability, and observability gates
- explain rejected alternatives and rollback
- close with production signals
Common weak answers
- Choosing CSR/SSR globally without route-level reasoning.
- Naming a state library before assigning state ownership.
- Ignoring degraded states and partial dependency failure.
- Treating frontend authorization as security enforcement.
- Saying "add monitoring" without metric names, thresholds, owners, and actions.
- Optimizing for team autonomy without naming runtime and governance cost.