The CritThe Crit

Portfolio Development

Design Critique vs Design Review Choose the conversation by its outcome

A critique helps the work become stronger. A review makes a decision. Here is how to prepare for both without turning feedback into theater.

Nikki Kipple
Nikki Kipple10 min readUpdated Sep 2026

The short read

  1. Critique improves

    Use it while the work can still change and you need observations, questions, or options.

  2. Review decides

    Use it when a decision owner can evaluate the work against visible criteria.

  3. Name the mode

    People can explore or decide in one session, but they should know when the mode changes.

Editorial diptych showing open design exploration beside a criteria-led final selection

Start with one useful difference

A design critique asks, what would make this work better? A design review asks, what decision can we make now? The names vary across teams, but the distinction matters because the people, evidence, and ending are different.

Critique is useful while the work can still respond to feedback. Review is useful when the group has enough evidence to approve a direction, request a revision, choose between options, or identify a blocker. Neither one has to be harsh or ceremonial.

Design critique

Improve the work

  • Question: What is helping or getting in the way?
  • Participants: People with relevant perspective or evidence
  • Output: Prioritized observations and things to try

Design review

Make the decision

  • Question: Does this meet the criteria for moving forward?
  • Participants: Decision owner plus constraint owners
  • Output: A recorded decision, conditions, and next owner

Choose the conversation you actually need

Start with the next outcome

The direction is still open
Run a critique.
Ask for observations and alternatives before the team becomes attached to one answer.
A specific part feels unresolved
Run a focused critique.
Frame the question around the hierarchy, flow, message, interaction, or other decision that can still change.
A milestone needs approval
Run a review.
Show the criteria, evidence, tradeoffs, and exact decision the owner needs to make.
The group needs both
Separate exploration from decision.
Use two meetings or two explicitly labeled phases, with time between them if the critique produces material changes.
The question is still vague
Hold a framing conversation first.
A critique cannot rescue an unclear objective, and a review cannot make a sound decision without criteria.

Prepare a critique around the work

Give people enough context to read the artifact without writing the critique for them. The presenter should explain the objective and constraints, show the current work, and say where feedback would be most useful.

  1. 1
    State the objective
    Who is this for, what should they be able to understand or do, and what stage is the work in?
  2. 2
    Name the constraints
    Include the requirements that genuinely shape the decision: content, platform, time, brand, technical limits, accessibility, or production.
  3. 3
    Ask a real question
    “Where does the hierarchy stop supporting the next action?” gives the group somewhere useful to look. “Thoughts?” does not.
  4. 4
    Show enough evidence
    Share the relevant flow, states, content, research, or alternatives. Do not make people infer the problem from one polished screen.
  5. 5
    Leave room to respond
    Capture observations before defending the work. Clarify facts, then decide what you want to carry into the next version.

Prepare a review around the decision

A review should not end with everyone wondering whether the work was approved. Put the decision and its owner in the invitation, then organize the presentation around the criteria that matter.

A review-ready packet

  • The exact decision needed and the person accountable for making it.
  • The objective, audience, and agreed success criteria.
  • The recommended direction and any meaningful alternatives.
  • Evidence that supports the recommendation, with important limits made visible.
  • Known risks, dependencies, accessibility concerns, and unresolved questions.
  • The consequences of approve, revise, defer, or stop.

Make feedback specific enough to use

Useful feedback connects something visible in the work to an objective, then explains the effect. It can suggest a direction without pretending there is only one correct solution.

Hard to act on

“The page feels confusing.”

The designer has to guess what you saw, why it matters, and where to begin.

Useful critique

“The two primary actions carry equal weight.”

“If starting a trial is the priority, consider reducing the visual emphasis of the secondary demo action and test whether the next step becomes easier to find.”

A feedback sentence can include

  • The element, moment, or behavior you observed.
  • The objective or expectation it affects.
  • The consequence for the person using or reading the work.
  • A question, option, or next test rather than an unexplained command.
  • A strength worth preserving when it helps define the revision boundary.

When the meeting changes modes, say so

Real teams do not always get a clean critique followed by a clean review. The practical answer is not another rule. It is a visible transition.

  1. 1
    Open in critique mode
    “For the first part, we are looking for anything that keeps this direction from meeting the objective.”
  2. 2
    Summarize what changed
    Group the observations into resolved questions, possible improvements, and issues that need new evidence.
  3. 3
    Call the decision point
    “We are moving into review. The decision is whether this direction can proceed with these named revisions.”
  4. 4
    Defer when the evidence changed
    If the critique exposed a material problem, give the work time to respond instead of forcing approval on the original schedule.

Close the loop while the conversation is fresh

Feedback only becomes useful when someone carries it into a next step. Nielsen Norman Group recommends an immediate recap and a later follow-up that connects the evolving design to the feedback that shaped it.

After a critique
Record what you heard, what you will try, what you are not pursuing, and why.
The designer owns the response; contributors should be able to see that their feedback was understood.
After a review
Record the decision, conditions, owner, due date, and next decision point.
A vague “looks good” is not a durable approval record.
After the work changes
Show the before and after, including feedback that did not become a change.
Closing the loop builds trust and improves the next conversation.

Async feedback needs the same contract

A link and “let me know what you think” transfers the framing work to everyone else. Whether the conversation happens in a document, design file, video, or meeting, include the objective, stage, requested outcome, and deadline.

  • Say whether you want critique, a decision, or factual review for errors and constraints.
  • Point people to the relevant screen, page, flow, or version.
  • Keep comments connected to the visible work instead of starting parallel threads.
  • Ask contributors to label blockers, questions, suggestions, and preferences when the distinction matters.
  • Post the summary and decision in one durable place.

For a more detailed facilitation sequence, use the design critique guide.

Sources and further reading

QuestionsAnswers

Questions, answered.

A few practical details before you keep going

Share this resource

Nikki Kipple

Written by

Nikki Kipple

Product Designer & Design Instructor

Designer, educator, founder of The Crit. I've spent years teaching interaction design and reviewing hundreds of student portfolios. Good feedback shouldn't require being enrolled in my class — so I built a tool that gives it to everyone. Connect on LinkedIn →

Want a clear outside read before the decision?

Send the actual work and the question behind it. We will respond to the artifact, not hand you a generic meeting template.

Review my design →

Continue Reading

All resources →