Design Critique That Improves Work, Not Feelings

Eight designers in a Zoom room. Forty-five minutes. Three "I love the type hierarchy" comments. Two "have you tried it in dark mode" asides. One person who wasn't paying attention but said "looks great." The presenter logs off feeling validated. Monday morning, the file ships unchanged.

That's not critique. That's group therapy with a Figma background.

If your last five critiques produced zero file diffs, you don't have a critique practice. You have a recurring meeting that costs your team roughly six designer-hours a week and produces nothing. The bar I hold critique to is brutally simple: the artifact has to be different after the session than it was before. Not the presenter's feelings. Not the room's vibes. The file.

Here's how to actually run one.

Critique vs. Feedback Are Not the Same Thing

This is the first place teams get lost. They use the words interchangeably and then wonder why their sessions don't move the work.

Feedback is broad reaction. "I don't like the blue." "This feels heavy." "Something's off." It's directionally useful but unstructured. You collect it from users, from PMs, from your partner who happens to walk past your monitor. Feedback has no contract. The giver has no obligation to tie their reaction to anything specific.

Critique is structured evaluation against a stated goal. "The CTA color fails AA contrast on the muted background, so bumping it from #6B7280 to #4B5563 brings it to 4.6:1." "The empty state buries the primary action below the fold on mobile breakpoints, so moving it above the illustration matches the user's read order." Critique cites the goal, names the problem, and points at evidence.

You need both. But you can't run critique like a feedback session and expect different results. The session has to start with a stated goal, and every comment has to ladder back to it. If a reviewer says "I don't like the blue" and the brief was about IA, that comment is feedback, not critique, and it gets parked.

Make this distinction explicit at the top of every session. "We're doing critique today against the brief, not open feedback. If you have feedback that isn't in scope, drop it in the doc and we'll triage after." Twelve seconds. Saves forty minutes.

The Framing Brief Is the Presenter's Job

No brief, no critique. This is non-negotiable.

Before anyone reviews anything, the presenter writes three things at the top of the Figma file or doc:

The problem being solved. Not the feature. The user problem or business problem the design is meant to address. "Reduce drop-off in onboarding step 3" is a problem. "Redesign onboarding step 3" is a task.
The constraints. Technical (what eng confirmed possible), brand (what design system rules apply), timeline (sprint deadline, dependencies), research (what's already been validated, what hasn't). This is where you preempt 80% of the unhelpful comments.
The kind of feedback wanted. Directional ("does this approach work at all?"), detail polish ("micro-copy and spacing"), accessibility ("contrast, focus states, screen reader flow"), IA ("is this the right structure?"), copy ("does the language land?"). One or two categories, not all of them.

Ninety seconds of writing. The presenter reads it aloud at the top of the session, or, better, the reviewers read it before the session and show up already oriented.

Framing Brief Template

## Critique Brief — [Feature/Flow Name]
Date: [date] · Presenter: [name]

### Problem
[1-3 sentences. The user or business problem, not the task.]

### Constraints
- Tech: [what eng confirmed]
- Brand/system: [relevant design system rules, exceptions]
- Timeline: [ship date, blockers]
- Research: [what's validated, what's assumed, gaps]

### Feedback wanted
[Pick 1-2: directional / IA / detail polish / copy / accessibility / interaction]

### What's NOT in scope
[Decisions already made, conversations parked for later]

### Open questions
[2-3 specific things you want help with]

The "what's NOT in scope" line is the single highest-ROI part of the brief. It's where you say "we're not relitigating whether this should be a modal vs. a side panel. That's decided." Saves the session from time-traveling backward.

Ban "I Like." Use "What's Working."

"I like" anchors on taste. "I like" tells the presenter how the reviewer feels, which is irrelevant to whether the work is good. "I like" is also impossible to act on. What do you do Monday with "Sara likes the type hierarchy"?

Replace "I like" with "what's working against the stated goal" and "what's not working against it." Same instinct, different output.

Bad: "I really like how clean this feels."

Better: "Against the goal of reducing onboarding drop-off, the simplified visual hierarchy is working. The primary CTA is the brightest element on screen, which matches what we want users to do first."

The second version (a) ties to the brief, (b) names the specific thing working, and (c) explains why it's working. The presenter knows what to keep. The reviewers know what's load-bearing in the design.

This sounds pedantic. It is. Design critique is a craft skill, and craft skills require pedantic vocabulary. Teams that ban "I like" for two months stop needing the rule because the new vocabulary becomes habit. Teams that don't, never improve.

Async vs. Sync — Default Wrong, Pay Forever

Most teams default to sync critique for everything and burn four to six designer-hours per session that didn't need to be live. Here's the rule:

Async (Loom + Figma comments, 24-hour window):

Detail polish (spacing, micro-copy, icon choice)
Accessibility audit (contrast, focus states, semantic structure)
Edge case review (empty states, error states, loading states)
Copy review (voice, tone, scanability)
Final polish before ship

Sync (30-45 minute live session):

Directional calls: is this the right approach at all?
IA debates: five reviewers will disagree and need to argue it out
Novel patterns: anything not in the design system that requires a judgment call
Cross-functional input: when PM and eng need to be in the room
Stuck work: when the presenter has been spinning and needs unblocking

The async default works because async forces written, considered comments. People can't ramble or perform. Reviewers watch the Loom, drop comments in Figma tied to specific frames, and the presenter can address them in batches. A 45-minute sync session compresses to a 6-minute Loom + 30 minutes of distributed review = fewer total hours, often better quality.

The sync default fails because it pulls eight people into a room for one person's work, where five of them have nothing meaningful to say about that specific surface but feel obligated to talk anyway. That's where "I like the type hierarchy" comes from.

Pick the mode based on the brief's "feedback wanted" field. Detail polish? Async. Directional? Sync. If you're not sure, async first, then escalate to sync if the comments expose disagreement that needs live resolution.

The Defensive Designers — Name Them, Redirect Them

Defensiveness kills critique faster than bad feedback does. The presenter who can't sit still for three uninterrupted minutes of review will gut the session. Three patterns to name and redirect:

The Explainer. Every comment gets met with "but the reason I did that was..." The Explainer treats critique as a misunderstanding to clear up rather than information to absorb. The work doesn't change because the Explainer doesn't change.

Redirect script: "Note that, let's keep going. We'll come back to context at the end if there's time."

The Deflector. Every comment gets met with "yeah but engineering said..." or "yeah but PM wants..." The Deflector outsources the decision to absent third parties so they can't be held accountable for the design choice.

Redirect script: "That's a constraint conversation, not a critique one. Capture it in the doc as a follow-up. We're evaluating the artifact in front of us against the brief."

The Rewinder. Five minutes into critique, the Rewinder re-presents the brief, the user research, the previous explorations, the meeting where the decision was made. The Rewinder is buying time and trying to relitigate decisions in front of an audience.

Redirect script: "We're past framing and landing on the work. If a decision needs to be reopened, that's a separate session with the original deciders."

Three scripts. Memorize them. The first time you use them in a session, it will feel uncomfortable. By the third session, the team adapts and the patterns mostly disappear. By the fifth, the team starts policing themselves.

Presenter Norms

If you're presenting, here are the rules:

Don't defend in real time. Write it down. Reviewers say something you disagree with? Note it. Don't argue. The fastest way to kill a critique is to spend it negotiating instead of listening. After the session, address the notes in your action items.

Don't ask "does this work?" It invites taste comments. Ask "does this solve [stated problem] given [stated constraints]?" That's a question reviewers can answer concretely.

Don't present 14 screens. Present the 3 with the open question. If you bring 14, reviewers will comment on all 14 and dilute attention from the actual decision you need help with. Pick the screens where the decision lives. Park the rest in an appendix.

Don't perform. No "okay so I went through like fifty iterations and..." Show the work. The journey is in your head and not load-bearing for the reviewers. They need the current state, the brief, and your open question.

End on the question. Last slide before discussion: "What I need from you today is X." It tees the room up. Without it, you get a smear of unrelated comments.

Reviewer Norms

If you're reviewing, here are the rules:

Tie every comment to the brief. "Against the IA goal, the third-tier nav adds two clicks for a primary task. Consider promoting it to top-level." Not "I'd promote that to top-level." The first version is critique. The second is unsolicited art direction.

Diagnose before you solution. "This nav feels confusing because the labels mix mental models, where some are nouns (Inbox, Reports) and some are verbs (Compose, Review)" is a diagnosis. "Use a hamburger menu" is a solution. Diagnose first. Let the presenter decide on the solution. They have context you don't.

No re-litigating. If the brief says "the modal pattern is decided," don't open with "I still think this should be a side panel." That's not critique. That's you trying to win an old argument.

No design-by-committee. Reviewers advise. The presenter decides. If five reviewers contradict each other, the presenter weighs the input and picks a path. The session does not vote. Voting on design produces mush.

Match the depth to the brief. If the brief says "detail polish only," do not show up with directional concerns. Park them in the doc as follow-ups. Respect the scope.

Reviewer Comment Template

Against [goal from brief], [observation tied to specific frame/element]. Consider [direction or principle, not a solution].

Example:

Against the goal of reducing onboarding drop-off, the secondary CTA on screen 3 competes visually with the primary action. Both are filled buttons in similar weights. Consider differentiating hierarchy so the primary action wins attention.

That's the entire formula. Goal · observation · direction. Comments that don't fit this shape are usually not critique.

Every Critique Ends With Action Items, or It Didn't Happen

This is the rule that turns critique from a meeting into a practice.

At the end of every session (sync or async), the presenter (not the loudest reviewer, not the design manager, not the room's consensus) writes 3-7 action items in the file:

What's changing.
What's staying.
What's a follow-up question for PM, eng, research, or another designer.

Posted in the team channel within 24 hours. Linked back to the file. Tagged with the next checkpoint date.

Action Items Template

## Critique Action Items — [Feature/Flow] — [Date]
Presenter: [name]

### Changing
- [ ] [Specific change tied to a critique comment, with frame reference]
- [ ] [Specific change]
- [ ] [Specific change]

### Staying (and why)
- [Decision held] — [1-line rationale tying back to brief or constraint]
- [Decision held] — [reason]

### Follow-ups
- [ ] @pm — [specific question]
- [ ] @eng — [specific question]
- [ ] @research — [specific question]

Next checkpoint: [date / async-or-sync]

No action items, no critique. If the presenter can't write 3-7 items, either the session was unfocused or the brief was wrong. Both are diagnoseable problems. Both are fixable. What's not fixable is a team that runs critique for a year and produces nothing tracked.

Common Pitfalls

Critiquing without a brief. Most common failure. The session becomes feedback, then becomes vibes, then becomes nothing.

Mixing critique with stakeholder review. Different audience, different rules. Stakeholders care about scope, brand, and risk. Reviewers in critique care about craft. Combining them produces a session where neither group gets what they need. Run them as separate meetings with different agendas.

Running critique as a status update. "Here's where I'm at this week." That's a standup. Critique requires an open question and a brief. If you don't have those, skip critique and just post the file in the channel.

Skipping critique because "we're moving fast." The teams that skip critique to move fast ship the most regressions and the most last-minute scrambles. Critique is a forcing function for thinking before shipping. The 45 minutes you save by skipping it costs you four hours of fix-up after launch.

Letting the most senior voice override the brief. The Staff Designer who shows up and says "I just don't like this direction" without tying it to the brief is doing damage. Seniority does not exempt anyone from the comment template. If the senior voice has a directional concern, they raise it as a follow-up question and convene the right people. They don't hijack the session.

The Async Critique Loom Script

For async sessions, the presenter records a 4-7 minute Loom. Anything longer and reviewers stop watching. Structure:

0:00-1:00, Brief. Read the framing brief. Problem, constraints, feedback wanted, what's not in scope.
1:00-4:00, Walk the work. Three or four key frames. Narrate the user's path. Don't explain every choice. Let the reviewers identify what stands out.
4:00-5:00, Open questions. State the 2-3 things you specifically want input on.
5:00-end, How to respond. "Drop comments in Figma tied to frames. Use the format goal · observation · direction. Deadline is [24-48 hours]. I'll post action items by [date]."

Reviewers watch on 1.5x speed, drop comments async, presenter compiles. Total team time is roughly half what a sync session costs.

How You Know It's Working

Stop measuring critique by "did everyone feel heard." Start measuring by:

Action items per session. Target 3-7. Below 3 means the session was unfocused or the brief was too narrow. Above 7 usually means the brief was too broad.
File diff within 48 hours. Did the artifact actually change? Pull a before/after screenshot. If the file looks identical 48 hours after critique, the session failed.
Reviewer comments tied to brief. Sample 20 comments from the last month. What percentage tie back to the stated goal? Target 80%+. If you're below 60%, your team is running feedback sessions and calling them critique.
Presenter satisfaction (binary). "Did this critique change my work?" Yes or no. No 1-5 scales. The answer is yes or it's no. Track it monthly.

If you run these four metrics for a quarter and the trend is flat, the practice isn't working and you need to rebuild it from the framing brief up. If the trend climbs, the practice is doing its job — protecting the work, not the presenter.

That's the whole job. Critique exists to make the artifact better. Not to make the presenter feel seen, not to give reviewers a stage, not to fill a recurring slot in the calendar. Better artifact, written action items, file changes within 48 hours. Anything else is overhead.

Product Designer Playbooks