Every RADIO step builds on the one before it — so the whole design is only as good as the requirements you start from. The R step looks small, but skip it and you'll spend the rest of the interview confidently solving the wrong problem.
The map
The RADIO framework, in one glance
RADIO is a repeatable five-step process for any frontend design problem — in an interview or on the job. Each letter is a stage; tap any to see what it covers. This lesson is the first one: R.
R · Requirement Exploration
Clarify the problem before building. Ask sharp questions, separate functional from non-functional requirements, and lock the scope.
Why order matters
The steps are sequential on purpose. Requirements feed the architecture, the architecture frames the data model, the data model shapes the interfaces, and only then do optimizations have something concrete to bite into.
The R in RADIO
What requirement exploration is
Requirement exploration is the act of clarifying an ambiguous problem before writing a line of code. You ask a handful of useful, to-the-point questions until you genuinely understand what you're being asked to build — and, just as importantly, what you're not.
Three words carry the weight here. Useful: questions that actually move your understanding forward. Problem: the thing you're being asked to solve — which is usually bigger and fuzzier than it first appears. Ambiguity: the gaps the prompt leaves open, deliberately or not, that you have to close.
The core insight
The interviewer almost always leaves part of the problem vague on purpose — to see whether you'll charge straight at the code, or stop and scope it first. The candidate who scopes first is the one who looks senior.
Same step, two settings
Two flavors: interview vs. user story
“The problem” reaches you in one of two ways, and the kind of questions you ask shifts with it:
🧑💼 Interviewer
Design a news feed.
🧑💻 You
Local or remote search? A max number of items? Virtualized when it grows?
🧑💼 Interviewer
Good questions — let's say remote, cursor-based, virtualized.
A short, open prompt → you probe the edges.
The interviewer gives a short prompt — “design a news feed”, “design a dropdown”, “design a carousel.” It's intentionally open. Your job is to probe the edges: local or remote search? a maximum number of items? virtualized when the list grows?
They're evaluating how you think, not just the final box-diagram. Asking the right questions — and making reasonable assumptions when there's no answer — is half the score.
Try it
Ask the right questions
You're in an interview. The prompt is deliberately broad. Pick the questions worth asking — sharp ones surface real requirements; low-signal ones are implementation details you can defer.
🧑💼“Design a Facebook-style news feed.”0/4 sharp questions
Tip
Watch the interviewer's answers for their focus area. The moment they give you extra detail on one topic (say, performance), they're telling you where to spend your time. And when they have no number for you — “how many users?” — state an assumption (“let's say ~1,000 concurrent”) and move on.
The two buckets
Functional vs. non-functional
Whatever questions you ask, the requirements you walk away with fall into two buckets. Functional requirements describe what the system does from a user's perspective — the behaviors and features. Non-functional requirements describe how well it does them — performance, accessibility, i18n, security, testing.
Functionalwhat the system does
Scroll an infinite feed
Create a post
Comment on a post
Non-functionalhow well it does it
Fast & smooth (performance)
Accessible (keyboard, SR)
Localized + RTL (i18n)
Now sort each requirement into the right bucket:
0/6 sorted
User can scroll an infinite feed of posts they follow
User can create a post with text, links, and images
Feed must reach interactive in under 2s on 3G
User can comment on a post
UI must support RTL and the user's preferred language
Feed must be keyboard-navigable and screen-reader friendly
Put it together
Worked example: the Facebook feed
Facebook is enormous — feed, groups, profiles, messenger, marketplace. The first move on a prompt that big is to scope down: get the interviewer to confirm which slice matters. Usually it's the feed itself:
Everything Facebook does
feed · groups · profiles · messenger · marketplace
↓
Scope down → the News Feed
confirm the one slice that matters
↓
Concrete requirements
3 functional · 3 non-functional
From there, the requirements you'd write down look like this — tap to expand:
Don't inflate the problem
If you wander into video uploads, groups, and messenger unprompted, you'll run out of time solving a problem nobody asked for. Finish the functional requirements first, then focus on the areas the interviewer actually flagged.
Practice
Check your understanding
Q1Sort each scenario
Functional or non-functional requirement?
User can react to a post with an emoji
All API calls must be authenticated and rate-limited
User can search posts by keyword
Core flows must have automated test coverage
Q2Multiple choice
What is the main purpose of the requirement exploration step?
Q3Multiple choice
You ask the interviewer how many concurrent users to expect, and they don't give a number. Best move?
Try it yourself
Design challenge
Take a deceptively small prompt — “design a typeahead search dropdown” — and write its requirement-exploration notes:
List five sharp clarifying questions you'd ask first.
Split the answers into functional and non-functional requirements.
Write one assumption you'd state aloud if the answer is missing.
If your list includes “local vs. remote search,” “max results,” “debounce / keyboard nav,” and “RTL,” you're thinking like the R step intends.
Key takeaways
→RADIO = Requirements → Architecture → Data model → Interface → Optimizations. R comes first because everything else depends on it.
→Requirement exploration means clarifying ambiguity with useful, to-the-point questions before you design anything.
→Requirements split into functional (what the system does) and non-functional (performance, a11y, i18n, security, testing).
→Read the interviewer's answers for their focus area, and when there's no answer, state an assumption and move on.
→Scope down first — finish functional requirements before chasing the areas nobody asked about.