How to Run a Design Critique That Improves the Work

A design critique has one job: make the work better. Many critiques fail at that job because they quietly turn into something else, such as a presentation, an approval gate, or a debate about personal taste. The structure below keeps the session focused on improving the design and makes sure the useful comments survive past the end of the meeting.

Keep critique separate from approval

Nielsen Norman Group's guide to design critiques distinguishes standalone critiques, gatherings "with the sole purpose of improving a particular piece of work," from design reviews, which evaluate a design against a set of criteria. Mixing the two causes predictable problems. When the people in the room can approve or reject the work, the presenter defends instead of listening, and critiquers adjust their comments to the politics of the room.

Pixar is a well-known example of keeping them apart. In a talk summarized by First Round Review, Ed Catmull described the studio's Braintrust, the group of filmmakers who give notes on films in progress: "One of the things we realized is that the Braintrust should have no authority." Because the group "could not tell the director what to do," he explained, the director never had to walk in on the defensive. The director decides what to do with the notes.

The same rule works on a product team. In a critique, feedback is input, and the designer, with their product partner, decides what to change. Sign-off happens in a different meeting, ideally after the designer has had time to act on the critique.

Choose a format

Different formats suit different work and different groups. Pick one before the meeting and tell people which one it is.

Round robin is one of the two facilitation approaches the NN/g guide describes. The Critical Response Process, devised by Liz Lerman in 1990 for feedback on creative work in progress, is worth learning even if you only borrow parts of it. Its four steps run in order:

1. Statements of meaning. Responders say what was meaningful, interesting, or striking in the work.
2. Artist as questioner. The maker asks their own questions about the work.
3. Neutral questions. Responders ask questions, which count as neutral "when they do not have an opinion couched in them."
4. Permissioned opinions. Responders offer opinions only with permission, in a set form: "I have an opinion about _____, would you like to hear it?" The maker can say no.

The order matters. By the time opinions arrive, the maker has already heard what works and has steered the conversation toward what they most need help with.

Assign roles

A critique without roles defaults to being run by the loudest person in it. Assign these before the session:

• Presenter. The designer whose work is on the table. They frame the goals, answer questions, and decide what to do with the feedback afterward.
• Facilitator. Keeps time, enforces the format, and redirects comments that drift. The NN/g guide recommends rotating this role from critique to critique, so one person does not always steer the outcome.
• Critiquers. Everyone else. Their job is to evaluate the work against the goals the presenter set.
• Note-taker. Someone other than the presenter, so the presenter can listen. Notes go somewhere the whole team can see.

On a very small team the facilitator can also take notes, but the presenter should not do either job.

Frame the goals before anyone comments

Feedback is only useful relative to a goal. Before showing the work, the presenter covers:

1. The problem. Which user need or business outcome this design serves.
2. The audience and context. Who uses it, on what device, in what situation.
3. Constraints. Technical limits, deadlines, components that must be reused.
4. Stage. Whether this is an early concept or close to final, which changes what feedback is useful.
5. The question. What you want feedback on, and what you do not. For example: "I want to know whether the order of steps makes sense. The visual styling is not final."

NN/g's critique cheat sheet recommends sending the agenda, with the scope and the designs attached, before the meeting, so people arrive having already looked at the work.

Rules for giving feedback

Share these at the start of every critique until the team no longer needs the reminder.

• Tie each comment to a goal. "A first-time user may miss this button, and uploading a file is their first task" is useful. "I don't love this button" is not. When a comment arrives as pure taste, the facilitator can ask which user or goal it affects.
• Describe the effect, not the fix. "I couldn't tell which option was selected" leaves the designer room to solve the problem. "Make it blue" does not, and it may fix the wrong thing.
• Talk about the work, not the person. Say "this layout," not "you."
• Ask before you prescribe. A question often surfaces a constraint the critiquer did not know about.
• No directives. The NN/g guide sums up the principle as "conversation rather than command" and warns that directives "can very quickly ruin the exact purpose of the critique."
• Park tangents. Hypothetical scenarios and broad strategy questions go on a visible parking list for another meeting.

Capture action items

Comments that live only in people's memories are easy to lose. The note-taker records each point along with who raised it. Afterward, the presenter sorts the list. NN/g's article on derailed critiques suggests three buckets:

• To do. Feedback you agree with and can act on right away.
• To persuade. Suggestions you disagree with or that conflict with the project goals. You will need to make your case and keep the conversation going.
• To clarify. Items that need more context before you can decide.

Give each item in the first bucket an owner, usually the presenter, and a target date. Post the sorted list where critiquers can see it, so they know their comments were heard even when the answer is no. Then open the next critique with a quick look at what changed since the last one.

A 45-minute agenda

A repeatable structure makes critiques easier to run and easier to attend. One version:

1. Framing, 5 minutes. The presenter covers the problem, audience, constraints, stage, and question.
2. Walkthrough, 10 minutes. The presenter shows the main flow. Only clarifying questions are allowed.
3. Silent review, 5 minutes. Everyone writes comments on their own.
4. Discussion, 20 minutes. The facilitator runs the chosen format and groups similar comments.
5. Wrap-up, 5 minutes. The note-taker reads back the key points, and the presenter says which ones they will look at first.

Keep the group small enough that everyone speaks. If the invite list keeps growing, split the session or rotate attendees. Judge each critique by one test: how much of what was said shows up in the next version of the design.