In short
A design critique meeting helps a designer improve work in progress. The presenter states the goal and the feedback they need, reviewers describe problems against that goal rather than proposing solutions, and someone other than the presenter writes the feedback down so the presenter can listen.
A design critique meeting is where a designer shows work in progress and gets feedback to improve it. It works when the presenter says what the design is for and what feedback they need, reviewers describe problems against that goal instead of proposing their own solutions, and somebody other than the presenter writes the feedback down.
This guide covers a design crit format you can use as is, how to phrase feedback, what design review meeting notes should contain, and why the presenter should not be the one taking them.
How to run a design critique meeting
- Book a fixed slot per piece of work. 15 to 20 minutes each works for most teams. Name the presenter and the note-taker for each slot in the invite.
- The presenter sets the frame. In two minutes: the problem, who it is for, the stage the work is at, and the kind of feedback they want ("the flow, not the colours").
- Show the work. Walk through it once without interruption, or let reviewers look at it silently for a few minutes.
- Reviewers ask clarifying questions first. Questions about what they are looking at, not opinions.
- Reviewers give feedback against the goal. Each point as a problem: what they tried, what they expected, what happened.
- The presenter listens and asks follow-ups. They do not defend the design. "Tell me more about that" is the most useful thing they can say.
- The note-taker writes each point with who raised it. Word for word where the wording matters.
- The presenter says what they will do next. One or two sentences at the end of the slot. The note-taker records it.
Critique is not approval
Most crits that go badly are approval meetings in disguise. When the outcome of the meeting is a yes or a no, people present work as finished and defend it, and reviewers hold back or pile on.
| Critique | Approval review | |
|---|---|---|
| Purpose | Improve work in progress | Decide whether it goes ahead |
| Who decides | The presenter, afterwards | Named approvers, in the meeting |
| Feedback | Problems against the goal | Whether it meets the criteria |
| Good outcome | A list of problems to consider | A decision, recorded |
Keep them separate. If your team needs sign-off, hold it later, as its own meeting, with the criteria written down in advance. Record the decision like any other; the critique notes are its background.
Feedback as problems, not solutions
"Make the button bigger" is a solution. It might be the right one, but it skips the problem it solves, and the designer may know a better fix. Compare:
| Solution-shaped | Problem-shaped |
|---|---|
| Make the button bigger | I didn't notice there was a next step |
| Use a table instead | I couldn't compare the three plans side by side |
| Change the copy | I wasn't sure whether "Archive" deletes it |
| Move it to settings | I'd expect to change this once, not every time |
A simple pattern: what I was trying to do, what I expected, what happened. "I was trying to cancel, I expected it on this screen, I ended up in settings."
Two more rules make a crit work:
- Tie feedback to the goal the presenter stated. If they asked about the flow, feedback on colour can wait or go in writing.
- Say what works, specifically. "The empty state tells me exactly what to do" helps the presenter keep it. "Looks great" does not.
Why the presenter should not take the notes
A presenter who is writing is not listening. They miss the follow-up question they should have asked, they paraphrase feedback into what they already believed, and they write down the points they agree with more carefully than the rest. None of this is deliberate.
So:
- Name a note-taker for each slot who is not presenting. Rotate the job.
- The note-taker writes feedback as said, with the name of who said it, so the presenter can go back to that person.
- The presenter owns the next steps, not the note-taker.
For general note-taking habits, such as writing in the room and tidying straight after, see how to take meeting notes.
The design critique notes template
# Design crit — <project> — <date>
**Presenter:** <name>
**Note-taker:** <name>
**Reviewers:** <names>
## What the presenter asked for
- Problem: <one line>
- Stage: <sketch / wireframe / high fidelity / built>
- Feedback wanted on: <flow, content, visual, feasibility>
## Feedback
- <problem, in the reviewer's words> — <who>
- <problem> — <who>
## What works (keep)
- <specific> — <who>
## Questions to follow up
- <question> — <presenter to ask whom>
## Next steps (presenter)
- <what they will change, test or explore>A filled-in example
# Design crit — Harbour export flow — 2 October
**Presenter:** Priya
**Note-taker:** Tom
**Reviewers:** Ana, Marc
## What the presenter asked for
- Problem: exporting a month of reports takes four screens.
- Stage: clickable prototype.
- Feedback wanted on: the flow, not visuals.
## Feedback
- "I didn't realise the date range applied to every report." — Marc
- "I expected to see the file size before exporting." — Ana
## What works (keep)
- The summary step says exactly what will be exported. — Ana
## Questions to follow up
- Do Northwind's admins export for other people? — Priya to ask support.
## Next steps (presenter)
- Try the date range on the first screen; test with two customers.Recording a critique
Some teams record crits so the presenter can hear feedback again, or so someone in another time zone can catch up. Ask the room first. People give franker feedback when they know who will hear it later, and some would rather not be recorded while thinking aloud about a colleague's work. If anyone objects, take notes only.
If the team agrees, a transcript takes pressure off both the note-taker and the presenter. The presenter can listen fully, and look up a point afterwards instead of relying on memory. With Notey on a Mac, a remote crit is recorded as two tracks, your microphone and the call's audio, and transcribed on the Mac as it happens. Afterwards the presenter can search for a word like "date range", click the line, and play the feedback from that moment, or click the whole-meeting overview to jump to a point in the discussion. Finding a moment in a meeting recording explains those in detail. The transcript is a reference; the notes above are still what the presenter works from.
Common mistakes
- Approval disguised as critique. Say which meeting it is.
- Solutions instead of problems. Ask "what did you expect?" to turn one into the other.
- The presenter defending the work. Listen, ask, decide later.
- The presenter taking notes. Name someone else.
- Feedback with no names. The presenter cannot follow it up.
For how a critique fits among the other meetings a team runs, and what record each needs, see types of meetings.
Frequently asked questions
What is the difference between a design critique and a design review?
A critique is for improving work in progress; nobody approves or rejects anything. A review, in the sense of sign-off, decides whether the work can go ahead. Mixing the two makes people defend work instead of improving it.
How do you give feedback in a design critique?
Describe the problem against the goal the presenter stated, not the solution you would choose. "I couldn't find how to cancel" helps more than "add a red cancel button", because the designer may have a better fix.
Who should take notes in a design crit?
Anyone except the presenter. The presenter needs to listen and ask follow-up questions; writing slows both down.
How long should a design critique be?
Many teams run 30 to 60 minutes, often with more than one piece of work. Give each piece a fixed slot so the last presenter gets the same attention as the first.
What should design critique notes contain?
The goal the presenter stated, each piece of feedback as a problem with who raised it, questions the presenter wants to follow up, and what the presenter decided to do next.