How to run a design critique that people don't dread

Most design critiques produce a lot of feedback and very little clarity. The designer walks out with a long list of things to try and no real understanding of what "better" looks like. The reviewers feel like they contributed. The work doesn't improve.

The problem is almost always structural. Not the people, not the work. The structure.

The three things that kill a critique

No agreed framing. The designer presents. People react. Nobody said whether this is an early-stage exploration looking for directional feedback or a near-final design looking for polish issues. So some reviewers are asking big strategic questions and others are nitpicking button radii, and the feedback is useless because it's all aimed at different targets.

Feedback as direction. "What if you made this bigger?" is not feedback. It's a design suggestion from someone who hasn't done the design work. Feedback describes a problem: "I'm not sure what the primary action is." Direction proposes a solution: "make the button larger." The critique should produce problems. The designer should produce solutions. When reviewers start directing, the designer stops thinking.

No shared criteria. If nobody has said what this design is trying to do or who it's for, every reaction is equally valid and equally useless. "I love it" and "I hate it" are both feedback in this structure. Neither is actionable.

A structure that works

Before the presentation, the designer answers three questions and shares them with the room:

1. What stage is this work at? (Exploration, direction-setting, refinement, near-final)
2. What was I trying to solve?
3. What specifically do I need feedback on?

These aren't optional. They determine what kind of critique this is. A direction-setting critique should not be spending time on whether the font is right. A near-final critique should not be opening strategic questions about the approach.

During the presentation, the designer presents without interruption. No questions, no reactions. The reviewers are watching and noting, not responding.

Then the designer asks their specific question. Not "what do you think?" That opens everything. Something like: "Does this flow make it clear when someone would choose option A versus option B?" or "Does the information hierarchy match how a user would actually think about this problem?"

Responses address that question. If someone wants to raise something outside the scope, they flag it as out-of-scope and the designer decides whether to invite it.

The feedback format that actually helps

Good feedback in a critique has three parts: observation, interpretation, question.

Observation: What I see. Specific, not evaluative. "The confirmation step appears after the user has already committed to the action."

Interpretation: What I think that means for the user. "That might feel like a gotcha. They thought they were done and now there's one more step."

Question: A real question, not a loaded one. "Was that intentional? What were you trying to give them space to reconsider?"

This format keeps feedback grounded in the design rather than in personal taste. It makes the designer the authority. They know the answer to "was that intentional." And it creates a dialogue rather than a judgment.

The hard part: separating taste from craft

A lot of what gets presented as design feedback is personal preference. "I don't like this color" is not feedback. "I'm not sure this color reads as active against this background" is feedback. The distinction matters because one is about the reviewer's taste and the other is about whether the design is working.

Good critique leaders call this out gently when it happens. Not dismissively. Sometimes taste is relevant, especially when the reviewer represents the target user. But it should be named. "That sounds like a personal preference. Is there a functional concern underneath it?"

This takes practice and it requires the critique leader to have enough standing in the room to say it. Which means it can't be the junior designer running the meeting.

Who should be in the room

Every person in a critique should have a reason to be there. That reason should be either: they have expertise relevant to what's being evaluated, or they represent a perspective the designer needs.

"Everyone on the team" is not a reason. Large critiques are usually worse than small ones. More opinions don't produce more clarity. They produce more noise and a designer who's trying to satisfy ten people at once.

Three to five reviewers is usually the right size. One facilitator who isn't presenting. Someone who can speak to technical constraints. Someone who can speak to user needs. One person from outside the immediate team who will say the thing the team is too close to see.

---

The goal of a critique is not to have had a critique. It's to give the designer what they need to make the work better. That's a simple standard and it's the one most critiques miss.