How to Give and Receive Design Critique That Actually Makes Work Better

Design critique is one of the most important things a design team does together. It's also one of the most consistently mishandled.

Too many crits turn into approval sessions. People say "this looks great" and move on. Or they turn into pile-ons where whoever has the most confidence dominates. Neither produces better work.

Getting critique right is a skill — one for both the person presenting and the people giving feedback.

What good critique is actually for

Critique is not for evaluating whether design is finished. It's not for getting sign-off. It's for finding the weak points in your own thinking before they become problems in production.

The designer presenting should be coming in with questions, not just work. Where am I most uncertain? What tradeoffs did I make that I'm not sure about? What constraints did I work within that might be wrong?

If you go into a crit hoping everyone will confirm the work is good, you'll get less out of it than if you go in hoping someone will find the hole you didn't see.

How to present work in a crit

Start with context, not the design.

Before showing anything, cover: what problem you were solving, who you were solving it for, what constraints you were working within, and where you are in the process. Rough explorations need different feedback than near-final work. If you don't say which one this is, people will give you the wrong kind of input.

Then show the work. Then tell people specifically what you want feedback on.

"I'm confident about the overall structure. What I want input on is whether the empty states make sense and whether the hierarchy in the card component is landing."

Specific questions get specific answers. "What do you think?" gets you a scattered conversation about whatever catches people's eye.

How to give feedback that's worth receiving

Good design feedback names the problem, not the solution.

When you say "I'd move this button to the top right," you've taken ownership of the solution away from the person who will have to live with it. When you say "I'm not seeing this as a primary action from this screen — is that intentional?", you've surfaced an observation and left the designer to figure out what to do with it.

This distinction matters. The designer knows the constraints, the edge cases, and the full context of the decision. Your job as a reviewer is to surface what's working and what isn't — not to redesign the work in the meeting.

Be concrete about what you're responding to. "This feels off" is not feedback. "The contrast between the label and the background is hard for me to read at this size" is feedback. Name the specific thing, name what it's causing.

Separate observation from interpretation. "The primary action is below the fold on mobile" is an observation. "Users won't find the CTA" is an interpretation. Lead with the observation. The interpretation might be wrong. The observation usually isn't.

How to receive critique without getting defensive

This is harder than it sounds, especially when you've spent weeks on something.

The most useful practice is treating feedback as data about someone's experience of the work, not a verdict on whether you did a good job. Someone saying "I don't understand why there are two buttons here" is telling you they're confused — not that the design is wrong. Their confusion might be valid. Or it might be because they're missing context. Both are worth understanding.

Ask questions instead of explaining. When someone raises something, the instinct is to explain why you made the decision. Resist it. Ask what they're experiencing first. "What made you notice that? What were you expecting?" The answer will tell you whether you need to change the design or just improve how you're communicating it.

Write everything down. Even the feedback you disagree with in the moment. You'll process it differently after the session, and something that felt wrong in the room often turns out to be pointing at something real.

Running a crit that doesn't drift

If you're the one facilitating, your job is to keep the conversation productive and inclusive.

Time-box each piece of work. Without time limits, conversations run long on the first item and rush the last.

Call on quieter voices directly. "We haven't heard from you on this — anything you're noticing?" The best feedback often comes from the person who hasn't spoken yet, not the one who's been most confident.

End by asking the presenter: "What's the one thing you're taking away from this?" It forces synthesis, and it tells you whether the crit actually helped.

---

Teams that critique well produce better work faster. The habit compounds: feedback gets more precise, trust builds, and people bring their real work rather than finished work to crits.

The Senior Product Designer Playbook covers how senior designers build critique cultures, give feedback that develops the people around them, and use design reviews as a leadership tool — not just a quality check.