You're asked to 'design a component/feature'. What structure do you use to answer?
Whether you drive the interview with a repeatable structure instead of jumping straight to code.
RADIO: Requirements — clarify scope, users, functional + non-functional needs (a11y, i18n, perf, devices); state assumptions. Architecture — break into components and data flow; draw the boxes. Data model — what state exists, who owns it (server cache vs local UI state), shape of it. Interface/API — component props/events AND the network API (endpoints, pagination, payloads). Optimizations — performance (virtualization, caching, code-split), accessibility, error/empty/loading states, edge cases. Spend the most time on Requirements and the part the interviewer probes. Why it works: front-end system design is deliberately open-ended, so a repeatable structure stops you rat-holing on one detail and signals seniority — you're driving the interview, not reacting to it. Announce the five letters up front, then timebox: spend the first chunk clarifying requirements, sketch the architecture quickly, then dive into whichever axis the interviewer leans on (usually the data model or optimizations). Distinguish functional needs (what it must do) from non-functional ones (a11y, performance budgets, i18n, offline, security) — naming the non-functional axes unprompted is a strong senior signal. State assumptions out loud so scope gets corrected early, before you design the wrong thing.
EVERY frontend system-design prompt. Announce the framework up front so the interviewer can steer you.
R Requirements — scope, users, functional + non-functional (a11y, perf, i18n)
A Architecture — component breakdown + data flow diagram
D Data model — state shape, ownership (server cache vs UI state)
I Interface — component props/events + network API (endpoints, pagination)
O Optimizations — perf, a11y, error/empty/loading, edge cases