Design interview frameworks have a bad reputation, and it's deserved. Most of them are acronyms that turn a conversation into a recital, and interviewers can hear it happening — the candidate is working through steps rather than thinking about the problem in front of them.
But the alternative most people fall into is worse: no structure at all, which sounds like enthusiasm for the first two minutes and like wandering after five.
What follows is deliberately small. Four moves, in order, that fit any design round — portfolio, critique, challenge, craft, behavioural. Not because the rounds are the same, but because the thing being evaluated in all of them is the same: can you separate the problem from the solution, out loud, before you commit to one?
Why most frameworks make you sound worse
The acronym frameworks fail for a specific reason: they're checklists of topics, so candidates read them out. You can hear someone reaching the letter they memorised.
A useful framework isn't a list of topics. It's a list of moves — things you do to the problem — and moves are invisible when performed well. Nobody hears you framing; they hear a candidate who understood the question before answering it.
The four below are moves. If you find yourself naming them out loud in the interview, you're using them wrong.
Move 1 — Frame
Narrow the problem to one user and one job, and say what you're leaving out.
Every design prompt is deliberately too broad. "Design a better airport experience." "Improve our onboarding." The prompt is a test of whether you'll shrink it before you start.
Framing is three sentences: who specifically, what they're trying to get done, and what success would look like. Then — the part almost everyone skips — name what you're excluding and why: "I'm going to focus on first-time users rather than returning ones, because the drop-off data usually lives there and the two have opposite needs. Happy to switch if returning users are where the business problem is."
That last clause does a lot of work. It shows the narrowing was a choice rather than an oversight, and it invites the interviewer to redirect you cheaply — which they will, and which counts in your favour.
Move 2 — Explore
Generate at least two real directions before choosing. Name them.
The single most common failure in a design challenge is going deep on the first idea. It reads as decisiveness to the candidate and as tunnel vision to the interviewer, because they have no way to know whether you chose that direction or just landed on it.
Two named directions is the minimum. They need to be genuinely different — not two visual treatments of the same concept: "There are two ways to go. One is to reduce the work: fewer fields, smarter defaults, ask later. The other is to increase the motivation: show what they get before asking. Those solve different underlying causes, and which one's right depends on whether people are dropping out because it's hard or because they're not convinced yet."
You have now given the interviewer a decision to watch you make, which is what the round is for.
Move 3 — Commit
Pick one. Say why. Say what you gave up.
Exploration without commitment is the second most common failure, and it's the one that quietly costs senior candidates the role. Listing options and asking the interviewer which they prefer reads as collaboration and lands as avoidance.
Commit in one sentence, with the reason attached and the cost named: "I'd take the reduce-the-work direction, because we can ship it without a content project and it's reversible. What I'm giving up is that if the real problem is motivation, this makes the form shorter and changes nothing — so I'd want the drop-off point instrumented before we build it."
The three sentences that carry the whole round: what I'm solving and what I'm not, the two directions and how they differ, the one I'd take and what it costs. Everything else — sketches, flows, edge cases — is elaboration on those. Candidates who get all three out in the first five minutes have effectively already passed; the rest of the time is detail.
Move 4 — Stress
Break your own idea before the interviewer does.
Once you've committed, the instinct is to defend. The move that scores is the opposite: go looking for where it fails. Empty state, error state, the first run, the slow connection, the user with two hundred items instead of three, the person who doesn't read.
There's a specific version of this that lands hardest — naming what would make you abandon the direction entirely: "The thing that would change my mind is if most of the drop-off is happening before the form is even visible. Then this is the wrong fix and I'd go back to the motivation direction."
Candidates rarely do this, and it's the clearest seniority signal available in a design interview, because it's what separates someone with an opinion from someone with a hypothesis.
The framework on a real prompt
Here's the whole thing at speed, on a prompt you'll actually get.
Prompt: "Design a feature to help people cook more at home."
Frame. "That's broad, so let me pick a slice. I'll take people who already want to cook more and don't — not people who need convincing that cooking is good. Specifically the weekday evening case, where the decision happens at about six o'clock and the failure mode is ordering delivery instead. Success is one extra home-cooked meal a week. I'm explicitly leaving out weekend cooking, which is a hobby rather than a logistics problem."
Explore. "Two directions. The first treats it as a decision problem — at six o'clock you don't know what to make, so the fix is removing the decision: one suggestion, based on what's in your kitchen. The second treats it as a preparation problem — the failure already happened on Sunday when nothing was bought, so the fix is upstream, in planning and shopping. Those are genuinely different products."
Commit. "I'd take the decision problem. It's cheaper to test, it doesn't require me to change someone's weekend behaviour, and the moment of failure is the moment we'd intervene. What I'm giving up is that it can't help someone with an empty fridge — for them this is a worse experience, because we're suggesting something they can't make."
Stress. "Where it breaks: people who don't tell us what they have, so the suggestion is wrong twice and they stop trusting it. That's the main risk, and it means the first version should probably ask for five ingredients rather than a full inventory. And what would change my mind entirely — if it turns out people know exactly what they'd cook and still order delivery, then this is a motivation problem, not a decision one, and the whole direction is wrong."
That's about ninety seconds of speaking, and it contains a framed problem, two options, a decision, a cost, a risk and a falsifier. Most candidates spend those ninety seconds describing a recipe app.
How the four moves shift by round
The moves don't change. Their weight does.
| Round | Where the weight sits |
|---|---|
| Portfolio walkthrough | Frame — lead with the stakes, not the process. Then Commit: which decision was yours |
| App critique | Frame first, always. Ask who it's for before judging anything |
| Design challenge | All four, in order, with Explore and Commit doing the most work |
| Craft and systems | Commit and Stress — the trade-off you made inside real constraints |
| Collaboration and behavioural | Stress — the story where you found your own idea's failure, or someone else did |
The critique round deserves a warning. It's designed to feel like an invitation to be impressive, and candidates skip straight to listing flaws. Framing first — who is this for, what is this screen supposed to move — is what separates judgement from taste.
For the questions each of those rounds actually asks, the companion list is here: Product Designer Interview Questions.
When to drop the framework
If the interviewer redirects you, follow them. The framework is there to stop you drifting, not to be completed. A candidate who finishes all four moves while the interviewer is trying to talk about something else has used it exactly wrong.
And if you're rattled mid-answer — you've committed to a direction and realised it's weak — say so and move. That recovery is its own skill and it's worth practising separately: how to recover after a bad answer.
Practical target: take any prompt and give yourself ninety seconds out loud for all four moves — no sketching, no notes. If you run out of time before Commit, you spent too long framing; if you never reach Stress, you're defending instead of testing. Both are fixable, and both are invisible until you hear yourself do it.
