Q282: Requirement Gathering and Scope Control in System Design
What Interviewers Want To Evaluate
Interviewers want to know whether you can create order from an ambiguous prompt.
They are checking whether you ask useful questions, define scope, identify non-goals, prioritize the core workflow, and avoid designing a giant unfocused system.
Short Interview Answer
In frontend system design, requirement gathering means clarifying users, goals, core workflows, data, scale, performance, accessibility, security, and operational constraints before proposing architecture. I separate must-haves from nice-to-haves, define non-goals, state assumptions, and time-box the design around the most important user journey. Scope control keeps the answer deep enough to be useful without trying to solve every possible future problem.
Detailed Interview Answer
Ambiguity is normal in system design.
The interviewer may ask:
design Google Docs
design a dashboard
design a chat app
design an ecommerce product page
design a learning platform
Each prompt can become enormous.
Your first job is to constrain it.
Clarify The User
Ask:
who uses this?
how often?
on which devices?
novice or expert?
internal or public?
authenticated or anonymous?
single user or collaboration?
User type changes everything.
An internal operations dashboard should be dense and efficient.
A public learning app should be readable, resilient, and discoverable.
Clarify The Workflow
Ask:
what is the primary action?
what is the secondary action?
what does success look like?
what is the recovery path?
what is the most common flow?
what is the highest-risk flow?
Design the primary workflow first.
Then add support flows.
Clarify Data
Ask:
what entities exist?
what relationships exist?
what is read?
what is written?
what changes in real time?
what can be cached?
what is sensitive?
Data requirements drive API design, state ownership, caching, and rendering.
Clarify Scale
Scale includes:
users
data size
request rate
client device range
geography
team size
content update frequency
real-time fanout
Frontend scale is not only traffic.
It is also list size, bundle size, rendering cost, and organizational complexity.
Clarify Constraints
Constraints may include:
must be SEO-friendly
must work offline
must support low-end devices
must support accessibility
must integrate third-party auth
must protect private data
must deploy globally
must support white-labeling
Constraints shape architecture.
Do not treat them as footnotes.
Define Non-Goals
Non-goals protect the answer.
Examples:
not designing admin tooling in this round
not building full offline collaboration
not supporting anonymous writes
not optimizing for millions of live users yet
not designing mobile native apps
Non-goals are not laziness.
They are scope discipline.
Prioritize
Use buckets:
P0: core workflow
P1: important support behavior
P2: future enhancement
This gives your answer structure.
It also gives the interviewer space to redirect.
State Assumptions
State assumptions clearly:
I will assume authenticated users for saved progress.
I will assume content is public and mostly static.
I will assume practice snippets are private user data.
I will assume mobile web is required.
Assumptions make the design easier to evaluate.
Interview Example
If asked, "Design a frontend for a project management dashboard," ask:
is it internal or customer-facing?
what entities: projects, tasks, users, teams?
does it need realtime collaboration?
how large can task lists be?
what filters are critical?
what permissions exist?
what devices matter?
Then propose a scoped version.
Common Mistakes
Common mistakes include:
not asking questions
asking too many irrelevant questions
designing every possible feature
forgetting non-goals
not clarifying scale
not identifying sensitive data
assuming desktop only
assuming global state solves scope
Senior-Level Framing
The senior framing:
"I use requirement gathering to turn an open-ended prompt into a bounded design. I clarify users, workflows, data, scale, constraints, and non-goals before architecture."
Practice Prompt
Take the prompt:
Design a frontend for a collaborative study planner.
Write:
10 clarification questions
5 assumptions
5 non-goals
3 P0 workflows
3 P1 workflows
Final Mental Model
Good system design starts before architecture.
If the problem is fuzzy, the solution will be fuzzy.
Clarify scope first, then design with confidence.