What I Learned About Design Critiques

Design critiques shouldn’t feel like going to the dentist. But for most teams, they do.

I spent years running design critiques wrong. They were tense, defensive affairs where designers presented polished work and everyone else poked holes in it. Nobody liked them. Not the designers being critiqued. Not the people giving feedback. Certainly not me, stuck in the middle trying to keep things civil.

Then I watched a team do it completely differently. The designer showed rough, half-formed ideas. People asked questions instead of giving opinions. By the end, the solution was better and everyone felt good about it.

That’s when I realised: design critiques aren’t crucial because they catch mistakes. They’re crucial because they build shared understanding and better solutions through collaboration.

Scaling What Works

Growth Considerations

As teams grow, design critiques get harder. With five people, everyone can attend everything. With twenty, that’s impossible.

The temptation is to stop doing them. Don’t. Instead, scale them intelligently.

Create different formats for different needs. Not every critique needs the full team. Quick feedback on an interaction? Grab two people for fifteen minutes. Major UX direction? Full team, scheduled properly.

I’ve wasted hours in critique sessions because I treated every decision as equally weighty. Quick decisions need quick critique. Strategic decisions need proper time and the right people.

Rotate participation. Don’t make it the same five people every time. Fresh perspectives catch things regulars miss. The engineer who rarely joins design critiques might spot a technical constraint the designers don’t know about.

Create a critique culture early. The longer you wait to establish good critique practices, the harder they are to implement. Teams develop habits. Make sure they’re good habits.

Maintaining Quality

As critique becomes routine, the quality can drift. Sessions become rubber-stamping exercises or turn into design-by-committee disasters.

Guard against false consensus. Just because nobody objects doesn’t mean they agree. Silence in critique is dangerous. Draw out the quiet people. “Sarah, you look uncertain. What are you thinking?”

Separate feedback collection from decision-making. Good critique generates ideas and perspectives. The designer then makes decisions based on that input. This isn’t a democracy. The person closest to the problem makes the call.

I’ve destroyed good designs by implementing every piece of feedback. That’s abdication of design responsibility.

Keep the feedback actionable. “I don’t like it” isn’t helpful. “The hierarchy isn’t clear because the primary action blends with secondary actions” is helpful. Teach people how to give good feedback, not just any feedback.

The best critique I ever received: “I’m trying to complete task X and I can’t find where to start. Walk me through your thinking?” It revealed an assumption I’d made that wasn’t true for all users.

Implementation Approach

Best Practices

Let me share what actually works, distilled from years of critiques that ranged from brilliant to disastrous.

Show work in progress, not finished work. The earlier you get feedback, the cheaper it is to implement. Showing polished work invites nitpicking. Showing rough work invites collaboration.

Frame the context clearly. Start every critique with: What problem are we solving? Who is this for? What constraints exist? What specific feedback do we need? Without context, people give random opinions instead of useful perspectives.

Ask questions before giving answers. The first response in critique should always be clarifying questions. “What happens if the user does X?” “How does this work on mobile?” “What’s the expected flow from here?” Questions reveal assumptions.

Time-box ruthlessly. Thirty minutes max for most critiques. Longer than that, and energy drops. People stop engaging properly. Better to have two focused thirty-minute sessions than one rambling ninety-minute session.

Create psychological safety. If people fear judgment, they’ll show safe, boring work. Make it okay to show weird ideas. Make it okay to be wrong. The best designs often come from exploring terrible ideas first.

I once showed a design so bad the team literally laughed. Then someone said, “But what if we kept this part and changed that part?” We ended up with our best feature of the year. That only happened because it was safe to show bad work.

Tooling and Process

Don’t overcomplicate this. You need three things: a way to show work, a way to capture feedback, and a way to track decisions.

For showing work: Whatever design tool your team already uses. Figma. Sketch. Adobe XD. HTML prototypes. Doesn’t matter. The tool isn’t the point. The conversation is.

For capturing feedback: A shared doc everyone can access during the session. Not a formal template. Just notes. What questions were asked? What concerns were raised? What ideas emerged?

For tracking decisions: Make it clear what changed based on critique and why. This closes the loop and shows that critique actually matters. If nothing ever changes based on feedback, people stop giving feedback.

Process-wise, keep it simple:

Designer shares context (5 minutes)
Team asks clarifying questions (10 minutes)
Team shares perspectives and ideas (10 minutes)
Designer summarises what they heard (5 minutes)

That’s it. Don’t add ceremony. Don’t create review boards. Don’t require sign-offs. Just structured conversation leading to better decisions.

The Development Context

Technical Considerations

Designers and engineers speak different languages. Good critique bridges that gap.

Involve engineers early. Don’t wait until designs are “finished” to show engineering. By then, you might have designed something impossible or unnecessarily complex. Engineers in critique sessions can flag technical constraints before they become problems.

I’ve seen gorgeous designs thrown out after weeks of work because nobody checked if they were technically feasible. One conversation in critique would have prevented that.

Understand technical constraints without letting them dominate. Just because something’s hard to build doesn’t mean it’s not worth building. But you need to know the trade-off. Maybe that animation is six weeks of work. Maybe it’s two hours. The conversation changes dramatically.

Make technical trade-offs visible. When engineering says “that’s complex,” ask “how complex?” Get specific. The difference between “one day” and “two weeks” changes prioritisation dramatically.

Team Dynamics

The power dynamics in critique rooms matter more than people admit.

The highest-paid person’s opinion shouldn’t count more. I’ve watched great solutions die because someone senior didn’t like them. Guard against this actively. Ask juniors to speak first. Probe senior opinions: “Tell me more about why you think that.”

Protect the designer’s agency. Critique should inform decisions, not make them. If the room starts voting on design decisions, you’ve lost the plot. The designer considers input and decides. That’s how you maintain coherent design.

Address conflict directly. When two people fundamentally disagree, don’t paper over it. Explore both perspectives. Sometimes both are right for different contexts. Sometimes one has information the other lacks. Either way, the disagreement usually reveals something important.

Key Takeaways

Here’s what matters for design critiques that actually improve products:

Show work in progress, not polished work. Early feedback is cheap to implement.
Ask questions before giving opinions. Understanding context matters more than having quick answers.
Create psychological safety for showing bad work. The best ideas often emerge from exploring failures.
Time-box sessions ruthlessly. Thirty minutes of focus beats ninety minutes of rambling.
Involve engineers early in the critique process. Technical constraints discovered late are expensive.
Separate feedback collection from decision-making. Gather perspectives, then let the designer decide.
Scale critique formats as teams grow. Not every decision needs the full team.

Final Thoughts

Design critique is a skill. Like any skill, you get better with practice.

Your first few critiques will be awkward. People won’t know what to say. Designers will be defensive. Feedback will be vague. That’s normal. Keep doing it. The discomfort fades. The benefits compound.

The teams shipping the best products don’t have the best individual designers. They have the best collaborative design processes. Critique is how you build those processes.

Start this week. Pick one design someone’s working on. Gather three people. Spend twenty minutes asking questions and exploring ideas. See what happens.

You’ll probably do it badly at first. That’s fine. You’ll learn more from one messy critique than from reading ten articles about how to do it perfectly.

Because design critique isn’t about perfection. It’s about progress. It’s about building shared understanding. And it’s about shipping better products because more brains contributed to the solution.

The struggle is worth it.