Four screens. Seven form fields. A drop-off cliff between screens two and three. The interviewer slides a competitor's onboarding flow across the table and says: "Tell me what you see."

This is where most candidates blow it. They start talking about colour palettes. Button radius. "It feels a bit cluttered." The interviewer's pen stops moving. They've already heard enough.

Design critique interview practice exists because this scenario -- pulling apart a real product flow and proposing something better -- is one of the hardest formats in design, product, and marketing interviews. It tests whether you can see mechanics, not aesthetics. Whether you can diagnose why users abandon, not just point at what looks off. And whether you can propose a v2 that's more than a wishlist of things you'd personally prefer.

I've built dozens of these scenarios into MORT's interview practice simulations. The pattern is always the same: candidates who critique the surface fail. Candidates who critique the system pass.

Why Design Critique Questions Trip Up Even Senior Candidates

A design critique interview is a structured evaluation where a candidate is presented with an existing product flow -- often a competitor's -- and asked to identify what works, what fails, diagnose why users drop off, propose specific improvements, and explain how they'd validate those changes. It tests analytical design thinking, not visual taste.

What makes this format brutal is that it punishes two instincts most designers have internalised. The first is the instinct to be diplomatic. "There are some interesting choices here, but I might explore..." No. The interviewer wants a diagnosis, not a group therapy session. The second is the instinct to redesign everything. Proposing a total overhaul signals you can't prioritise -- and interviewers know that engineering time is finite.

According to the Nielsen Norman Group's 2024 UX career report, 64% of design hiring managers rank "ability to articulate design rationale" as their top evaluation criterion -- above portfolio quality, above tool proficiency. The critique format tests exactly this.

Here's the typical failure mode. A candidate looks at a four-screen onboarding flow with a drop-off between screens two and three. Screen two is a seven-field sign-up form. Screen three is an email verification step. The candidate says: "The form has too many fields. I'd reduce them." That's not wrong. It's just not enough. They haven't asked why there are seven fields. They haven't considered whether the drop-off is caused by the form itself or by the email verification wall that follows it. They've treated a symptom and missed the disease.

Interviewers are scoring against criteria most candidates never see:

  • Did you diagnose specific failure points, not vague impressions?
  • Did you reason about why the drop-off happens -- cognitive load, premature value gates, friction timing?
  • Did you propose a concrete v2 with rationale, not a feature wishlist?
  • Did you name how you'd validate the redesign before shipping?
  • Did you prioritise when constrained -- which single change matters most, and why?

How to Run a Design Critique That Actually Impresses

The candidates who nail this follow a repeatable structure. Not a script -- a diagnostic sequence that interviewers recognise as mature design thinking.

1. Narrate the user journey before critiquing anything. Walk through the flow as if you're a new user. Screen one: feature carousel -- four slides, auto-advancing. Screen two: sign-up form, seven fields. Screen three: email verification. Screen four: sample-data setup. Say what a user experiences at each step. This immediately shows you think in journeys, not screens.

2. Identify where friction meets intent mismatch. The drop-off between screens two and three isn't just "too many fields." It's a value-before-ask problem. The user has seen four carousel slides of features they haven't used yet, then been asked to hand over seven pieces of personal information, then told to go check their email before they can touch the product. They've been asked to invest trust without receiving value. Name that dynamic explicitly.

3. Diagnose the root cause, not the surface symptom. Good looks like: "The drop-off at screen three is likely driven by the email verification wall. Users who've filled out seven fields have already committed -- they're losing them at the verification step, which breaks momentum and introduces a channel switch. The form length is a secondary factor; the verification timing is the primary one." Bad looks like: "The form is too long and the flow feels dated."

4. Propose a specific v2 with clear rationale. Don't describe a dream state. Describe a first iteration. "I'd move the product experience before the sign-up form -- let users interact with sample data on screen one, hit the value moment, then ask for credentials. Reduce the form to three fields: name, email, password. Defer email verification until after they've completed setup. The hypothesis is that users who've experienced product value will tolerate the verification step." A Baymard Institute study found that moving value demonstration before account creation increases onboarding completion by 20-40% across e-commerce and SaaS flows.

5. Name your validation approach. This separates designers from decorators. "I'd A/B test the new flow against the existing one, measuring completion rate through to the sample-data screen. Secondary metric: seven-day retention, to confirm that faster onboarding doesn't just produce low-quality sign-ups. I'd want at least two weeks of data before calling it."

6. Prioritise ruthlessly when constrained. Here's where the real test lands. The interviewer tells you engineering can only ship one screen of changes this quarter. Two previous redesigns already performed worse. Now what? The right answer isn't "I'd need more data." It's a commitment: "Screen three -- the email verification wall. It's the highest-friction, lowest-value step, and it's where the measurable drop-off occurs. Defer verification to post-onboarding. It's a single-screen change with the highest expected impact, and it doesn't require touching the form or carousel logic that the previous redesigns may have already optimised."

What interviewers want to see: a candidate who can work within constraints rather than wishing them away. What they don't want: a candidate who treats every limitation as a reason to hedge.

Practice Makes the Difference

Knowing this structure and executing it live are different skills entirely. The gap is pressure. In a real critique interview, the interviewer doesn't sit quietly while you narrate. They interrupt. They add complications -- "the company has tried two redesigns already, both performed worse." They force trade-offs -- "pick one screen." They want to see how you think when your plan gets disrupted.

This is precisely why I built design critique scenarios into MORT's interview practice tool. One thing we discovered early on: candidates who read critique frameworks before practising performed worse on their first live attempt than candidates who went in cold. The framework created a false confidence that collapsed under the first curveball. It was only after three or four adaptive practice rounds -- where the AI interviewer pushed back, introduced constraints, and challenged reasoning -- that the framework became genuinely internalised rather than memorised.

The stakeholder management scenarios test a related muscle -- navigating competing opinions -- but critique questions add a layer that pure stakeholder exercises don't: you need to be right about the diagnosis, not just diplomatic about the process. And if you're preparing for marketing-adjacent roles, the campaign analysis scenarios share the same evaluate-then-propose structure.

The Instinct That Separates Good From Great

The single most valuable habit in a design critique interview is this: diagnose before you prescribe. Every failed critique I've observed -- hundreds of them through building MORT -- follows the same arc. The candidate sees something they'd personally change, skips the diagnostic step, and proposes a solution to a problem they haven't proven exists.

The best critiques don't start with opinions. They start with questions. Why does this screen exist? What user need is it serving? What data would tell me whether it's actually failing? Only then: here's what I'd change, and here's how I'd know if it worked.

Interviewers aren't looking for the candidate with the best taste. They're looking for the one who can prove their taste is earned.