A design critique improves work-in-progress; a design review evaluates readiness and makes a decision. You run critiques during exploration and iteration, when the goal is better work. You run reviews at milestones, when the goal is a go or no-go call.
The fastest way to tell them apart:
- Purpose: critique improves the work; review approves or rejects it
- Timing: critique happens mid-process; review happens at a gate
- Participants: critique invites peers and collaborators; review invites decision makers and approvers
- Mindset: critique asks "how can we make this better?"; review asks "is this good enough to ship?"
- Outcome: critique produces a prioritized revision list; review produces a recorded decision
Key Takeaways
Design critique improves work-in-progress through collaborative feedback, while design review evaluates readiness and produces a formal go or no-go decision.
| Point | Details |
|---|---|
| Know the core question | Critique asks how to improve the work; review asks if it's ready to ship. |
| Separate the meetings | Combining critique and review produces neither actionable feedback nor a clear decision. |
| Prep 24 hours ahead | Share the brief, constraints, and specific questions before the session to skip context setting. |
| Measure the right signal | Track the share of critiques that produce file diffs and reviews that end in a recorded decision. |
| Document with the right tool | Usepinhub's pixel-anchored comments and automated summaries turn scattered feedback into a clear revision brief. |
Table of Contents
- Why Design Teams Confuse Critique and Review
- Design Critique vs Review: Clear Definitions
- The Key Differences That Actually Affect Outcomes
- How to Run a Design Critique: Template and Facilitation Rules
- How to Run a Design Review: Checklist and Decision Flow
- How Language Shifts the Meeting
- When to Run Each: A Simple Workflow
- Common Pitfalls When Critique and Review Get Mixed
- What Actually Makes These Meetings Work
- Why We Insist on Separating Critique and Review
- Run Critiques and Reviews Without Losing the Thread
- Sources
- FAQ
Why Design Teams Confuse Critique and Review
Most teams don't fail because they lack feedback skills. They fail because they schedule one meeting and expect it to do two jobs. A recurring "design sync" invites both peers who want to explore ideas and executives who want a yes or no, and the result satisfies neither group.
The common failure modes repeat across teams of every size:
- No brief distributed beforehand, so the meeting opens with context-setting instead of substance
- A senior stakeholder (the HiPPO, or "highest paid person's opinion") redirects the conversation toward their preference rather than the stated goals
- Attendees arrive unsure whether they're there to suggest changes or approve a decision
- The meeting ends with vague sentiment ("looks good, keep going") instead of specific next steps
When a critique and a review get combined into one meeting, the result is often neither actionable improvement nor a clear decision. Separating the two, and inviting different people to each, restores both design velocity and decision clarity, according to TheCrit's analysis of the two formats.
Picture a typical Thursday design sync: a small group, under an hour, multiple opinions about typography, and a director asking "so are we shipping this Friday?" Nobody leaves with a revision brief. Nobody leaves with an approval. The meeting cost time and produced nothing to build on.
Design Critique vs Review: Clear Definitions
A design critique is a collaborative, improvement-focused conversation that happens during exploration and iteration. A design review is a formal, evaluative process that happens at a milestone, used to decide whether work is ready to move forward. Peter Merholz frames the distinction simply: critique asks "how can we make this better?" while review asks "is this good enough to move forward?"
That single-question test resolves most confusion on the spot. If the room is generating options, it's a critique. If the room is deciding between "ship" and "don't ship," it's a review.
Nielsen Norman Group's research on design critiques describes them as structured conversations focused on aligning work with user needs and goals, not personal taste. They work best with a defined structure and a capped participant list, not an open-door policy.
| Design critique | Design review | |
|---|---|---|
| Core question | "How can we make this better?" | "Is this ready to ship?" |
| Focus | The work, exploration, alternatives | Requirements, risk, business readiness |
| Tone | Collaborative, exploratory | Evaluative, decisive |
| Example prompt | "I notice the CTA competes with the hero image. What if we tested a single focal point?" | "Does this meet the accessibility requirement? Yes or no." |
| Timing | Mid-sprint, early concept, iteration | End of phase, before handoff, before launch |
A critique example question sounds like: "What happens if a user skips this step entirely?" A review example question sounds like: "Does this satisfy the checkout requirements we agreed on in the brief?" One opens possibilities. The other closes a loop.
The Key Differences That Actually Affect Outcomes
Purpose and timing get most of the attention, but the differences that determine whether a meeting was worth holding run deeper than that.
| Dimension | Design critique | Design review |
|---|---|---|
| Purpose | Improve the work through feedback | Evaluate readiness and make a decision |
| Timing | Mid-process, iterative, recurring | Milestone, pre-handoff, pre-launch |
| Mindset | Curious, exploratory, collaborative | Evaluative, criteria-driven |
| Who attends | Peers, designers, collaborators close to the work | Decision makers, approvers, stakeholders with sign-off authority |
| Expected outcome | Prioritized revision brief, file diffs | Explicit approval, decision log, named action owner |
| Success signal | Concrete changes get made afterward | A decision gets recorded, not just discussed |
The success signals matter more than they sound. Jakob Nielsen's writing on running UX critiques makes a blunt point: if critique sessions consistently produce zero file diffs, the team doesn't have a working critique practice. It has an expensive status meeting dressed up as feedback.
Track this instead of vague satisfaction: the percentage of critiques that produce specific file diffs the designer actually implements, and the percentage of reviews that end with a documented decision rather than "let's circle back." Teams that measure these two numbers tend to notice their meeting problems within a month, because the numbers rarely lie the way meeting vibes do.
For critiques, watch for:
- A prioritized revision brief exists by the end of the session
- At least one specific file diff gets assigned to someone
- The designer leaves with fewer open questions than they arrived with
For reviews, watch for:
- A yes/no/revise decision gets recorded, not implied
- An owner is named for any follow-up action
- The decision maps back to a specific requirement, not a general impression
How to Run a Design Critique: Template and Facilitation Rules
A critique that works starts before anyone opens their laptop in the room. Distributing the brief, constraints, and specific questions you want answered at least 24 hours ahead, what UX Tigers calls the "24-hour context share", moves feedback away from surface reactions and toward structural questions worth answering. Teams that skip this step spend the first ten minutes of every session just explaining what they're looking at.
A four-phase agenda keeps a 45 to 60 minute critique on track:
- Silent review (5 to 10 minutes). Everyone looks at the work individually and jots initial reactions before anyone speaks, so the loudest voice in the room doesn't anchor everyone else's opinion.
- Brief context (5 minutes). The designer states the goal, constraints, and the specific questions they want feedback on, not a walkthrough of every decision they made.
- Structured discussion (20 to 30 minutes). Participants share observations using "I notice" and "I wonder" framing rather than verdicts.
- Action summary (5 to 10 minutes). The facilitator recaps the specific items that will change, out loud, so everyone leaves with the same understanding.
Nielsen's guidance on group size recommends keeping critiques to three to eight people. Beyond that, the conversation fragments and quieter voices stop contributing entirely.
Language does the heavy lifting here. "Describe before you judge" keeps the group grounded in what's actually on screen rather than a first impression. Framing like "I notice the form has six fields" (observation) beats "this form is too long" (verdict) because it invites a conversation instead of ending one. To prevent a HiPPO from steering the room, the facilitator should collect silent input first and call on quieter voices before the most senior person weighs in.
Document the outcome using a simple revision brief: what's working, what needs to change, and a priority tag for each item, must-fix, should-fix, or explore-later. That structure is what Lenka Studio's process guide points to as the difference between a critique that sticks and one that evaporates by the next morning.
Pro Tip: If a designer needs more than fifteen minutes to explain a single screen, that's the real finding of the session. The design lacks clarity, not the presentation. Spend your remaining time there instead of debating button colors.
How to Run a Design Review: Checklist and Decision Flow
A review needs artifacts on the table before anyone discusses readiness. Atlassian's guidance on cross-team design reviews frames reviews as milestone gate checks, often run with a checklist and explicit acceptance criteria rather than open discussion.
Before scheduling a review, confirm you have:
- A requirements trace showing which acceptance criteria the design addresses
- QA notes or known issues, not a claim that "it's basically done"
- Any available analytics or usability validation tied to the decision
- A clear list of what specifically needs a yes or no answer
The decision flow should be explicit, not implied by tone in the room:
- Go. The design meets the stated requirements. Record the approval and the approver's name.
- No-go. The design does not meet requirements. Record why, specifically, and what needs to change before the next review.
- Revise and return. Minor gaps exist. Name the gap, the owner, and the date for re-review.
Reviews work best with defined roles: a decision maker who has final say, an approver representing each affected function (engineering, legal, brand), a technical reviewer checking feasibility, and a note-taker who records the outcome so it doesn't live only in someone's memory. Formal visual presentation matters here too. Visual Trick's guide on rendering styles that win client approval makes the case that how you present work at a decision gate shapes how fast stakeholders commit to it.
Translate the outcome into language a developer or client can act on: "Approved, pending the accessibility fix noted in item 4" reads clearer than "looks good, ship it."
How Language Shifts the Meeting
The words in the room signal which meeting you're actually running, even when the calendar invite says something else. Critique language stays exploratory: "I notice the nav collapses oddly on tablet. I wonder what happens if we test a hamburger pattern here." Review language stays binary: "This meets requirement 3.2. Approved" or "This does not meet the load-time requirement. Revise."
A facilitator can open a critique with: "We're here to make this better, not decide if it ships. Hold your verdicts, share your observations." A review opens differently: "We're here to decide go or no-go against the brief. Save exploratory ideas for the next critique cycle."
One overlooked detail: refer to "the design," not "your design." That small shift, drawn from UX Collective's guidance on improving critiques, creates distance between the work and the designer's identity, which makes people far more willing to hear hard feedback without getting defensive.
Pro Tip: Ban the phrase "I don't like it" from both meeting types. It's neither an observation a critique can build on nor a decision a review can record.
When to Run Each: A Simple Workflow
Sequence matters more than either meeting alone. Run critiques while the work is still moving, then close with a review once the direction is locked.
- Early concept. Weekly, informal quick critiques while ideas are still forming.
- Iteration phase. Bi-weekly formal critiques with the full four-phase structure once direction narrows.
- Late-stage polish. One final critique to catch structural issues before anything gets locked for review.
- Milestone gate. A single review, with decision makers only, to approve or send back.
Signals that you need a critique, not a review: open questions still outnumber answers, you're testing a hypothesis rather than confirming one, or the goal is still "explore" rather than "confirm." Signals you need a review instead: a deadline is attached, a specific stakeholder needs to sign off, or the question in the room is genuinely binary.
- Weekly quick crits for active work
- Bi-weekly formal crits for anything nearing a milestone
- A single review scheduled only when the team is confident the answer should be yes
That cadence, drawn from Lenka Studio's recommended rhythm, keeps critique from turning into a review in disguise just because a deadline is looming.
Common Pitfalls When Critique and Review Get Mixed
The same handful of problems shows up across nearly every team that hasn't separated these meetings deliberately.
- Mixed goals in one invite. Fix: split into two meetings with two distinct calendar titles and two distinct outcomes expected.
- No brief distributed beforehand. Fix: require the 24-hour context share as a standing rule, not a suggestion.
- Too many attendees. Fix: cap critiques at eight, cap reviews at the people who actually hold sign-off authority.
- A HiPPO dominates the room. Fix: collect silent input first, and give the facilitator explicit authority to redirect.
- No documentation afterward. Fix: require a written revision brief or decision log before the meeting is considered closed.
Different critique modes suit different goals too. 8th Light's breakdown of critique modes notes that a session focused on craft needs different participants than one focused on strategy or technical feasibility. Naming the mode in the invite prevents half the room from critiquing the wrong thing entirely.
What Actually Makes These Meetings Work
The practices that separate a productive critique from a waste of calendar time are consistent across the sources design teams trust most. The 24-hour context share saves meaningful setup time at the start of every session, according to UX Tigers' research on critique prep. Ending with specific file diffs, not general sentiment, is what Rework's design playbook identifies as the difference between a critique that improved the work and one that just filled a time slot.
Two numbers worth tracking every month: the percentage of critiques that end with assigned file diffs, and the average time-to-decision in reviews from "scheduled" to "recorded outcome." Teams that watch these catch drift before it becomes a pattern.
Tool features map directly onto these practices. Pixel-anchored comments eliminate the "which button do you mean?" back-and-forth that eats critique time. Guest reviewer access lets a client or stakeholder weigh in on a review without a login barrier slowing down the decision. Version history keeps the "which draft are we critiquing" question from ever coming up, and automated summaries turn a scattered comment thread into the revision brief a designer actually needs.
Pro Tip: Before your next critique, ask every attendee to submit one written observation ahead of time. It surfaces quieter perspectives and cuts the silent-review phase almost in half.
Why We Insist on Separating Critique and Review
Teams that run critique and review as two distinct meetings consistently move faster, not because the individual sessions are shorter, but because neither one carries the weight of the other's job. A critique freed from the pressure of "will this get approved today" produces more honest, exploratory feedback. A review freed from open-ended brainstorming produces a decision people actually trust.
The pattern shows up whenever a team adopts even a lightweight version of this split: fewer repeated conversations about the same screen, fewer meetings that end in "let's talk again next week," and revision briefs that designers can act on the same day. It's a structural fix, not a personality fix. You don't need better feedback-givers. You need two meetings instead of one confused one.
Run one separated critique this week, just one, with a real brief and a real revision list at the end, and compare it to your last mixed meeting.
Run Critiques and Reviews Without Losing the Thread
Usepinhub is built for exactly the split this article argues for: pixel-anchored comments that end the "which element are you talking about" confusion in a critique, and guest reviewer access that lets a decision maker weigh in on a review without creating an account first.
Three ways teams use it to shorten the critique to review cycle:
- Rapid async crits. Upload a screenshot or Figma frame, pin comments to specific spots, and let collaborators respond on their own time instead of scheduling a room.
- Review gating with a paper trail. Password-protect a review link, capture the go or no-go decision as a resolved comment thread, and keep a documented record instead of a verbal "looks fine."
- Automated action lists. Let Pinhub's AI summary turn a scattered critique thread into the prioritized revision brief your designer actually needs, instead of someone transcribing notes by hand.
Version history means nobody ever critiques the wrong draft again. If you're ready to try running a critique and a review as two separate, cleaner sessions, start with Pinhub on your next design cycle.
Sources
- Design Critique vs Design Review: You're Probably Doing It Wrong
- Critique is not review, and many other thoughts on an overlooked practice
- What are design critiques? (Nielsen Norman Group)
- How to Run a UX Design Critique (Jakob Nielsen on UX)
FAQ
What Is the Difference Between Critique and Review?
A design critique improves work in progress through collaborative feedback, while a design review evaluates finished work against requirements and produces an approval decision.
What Are the Modes of Design Critique?
Critique modes vary by focus, commonly covering craft, usability, strategy, research alignment, or technical feasibility, and choosing the right mode for each session keeps feedback relevant to the stage of work.
What Is the Purpose of a Design Critique?
A design critique exists to make the work better before it moves forward, using structured, collaborative feedback rather than a pass or fail verdict.
What Is a Design Review?
A design review is a formal, milestone-based evaluation that checks a design against requirements and ends with an explicit go, no-go, or revise decision.
How Do You Document Critique Outcomes So They Don't Get Lost?
A short revision brief listing what's working, what needs to change, and a priority tag for each item works best, and tools like Usepinhub can turn resolved comment threads directly into that list automatically.