A design critique has exactly one job: make the work better before it ships. Most of the ones we've sat in don't do that. They either collapse into a popularity contest over personal taste, or everyone defers to the most senior voice in the room and calls it alignment. Both outcomes skip the part where the work actually improves.
I've run hundreds of these sessions across very different teams, and the pattern holds regardless of seniority or experience level: an unstructured critique produces worse decisions than a structured one, even when every single person in the unstructured version is individually more talented. Structure isn't bureaucracy here — it's what stops a group of smart people from reliably producing a worse outcome than any one of them would have reached alone.
Critique the problem, not the pixels
The fastest way to derail a critique is to open with "I don't love this button color." That's a taste statement, and taste statements are unfalsifiable — there's no way to resolve them except by deferring to whoever has the most authority in the room. Every piece of feedback we allow has to trace back to the brief: what was this screen supposed to achieve, and does this choice help or hurt that goal.
- Replace "I don't like this" with "this makes the primary action harder to find, and the goal was faster task completion."
- If feedback can't be traced to a stated goal, it's a preference — note it, don't block on it.
- Separate "this is wrong" from "this is different from what I'd have done" — only the first one is actionable.
The structure that works
Context first, no exceptions
The presenter states the problem, the constraints, and what was tried and rejected — before anyone reacts to a single pixel. Half of bad critique feedback evaporates once the room understands what was already ruled out, and why.
Silent reactions before spoken ones
Everyone writes down their first response before the group discussion starts. This stops the first person to speak from anchoring the entire room's opinion.
Questions before verdicts
"What happens on a smaller screen?" produces more useful information than "I think this should be centered." We ask the room to spend the first round only asking questions.
Decisions get an owner and a deadline
A critique that ends in "let's think about it" has failed. Every open point leaves the room assigned to a person and a date, or it wasn't worth raising.
Who should be in the room
More voices is not more rigor. We cap critique at five people: the designer, one peer designer, one engineer who can flag feasibility early, and whoever owns the business outcome the screen serves. Anyone else gets the recording and an async comment window — their input matters, but a critique with twelve attendees produces consensus theater, not decisions.
When the room disagrees and nobody outranks anybody
The hardest critiques aren't the ones with a junior designer and a confident opinion from leadership — those resolve quickly, for better or worse. The hard ones are two peers with equal context who've reached opposite, well-reasoned conclusions. Letting that stalemate run out the clock is how a critique becomes a 45-minute non-decision.
- Name the actual decision-maker before the meeting, not during the disagreement — usually whoever owns the outcome the screen serves, not whoever has the most design experience in the room.
- If it's genuinely unresolvable by argument, make it an experiment instead of a debate — ship the cheaper version to validate, rather than relitigating taste for another thirty minutes.
- Write down the dissenting view even when it loses — the designer who was overruled deserves a record that their reasoning was heard, not just a decision that happened to them.
In closing
A good critique changes the work. If a session ends and nothing in the file is scheduled to change, it wasn't a critique — it was a status update wearing a critique's clothes.
