How Great Teams Approach Design Critiques

Design critiques have a reputation problem. Many teams avoid them because they devolve into opinion battles: “I prefer blue.” “Well, I prefer green.” Or they become brutal takedowns where junior designers present work and senior people tear it apart. Neither version produces better designs or healthier teams.

I’ve seen both extremes. At one company, design critiques were so toxic that designers would delay sharing work until the last possible moment, eliminating any chance for meaningful feedback. At another, critiques were so gentle and non-committal that nobody gave honest feedback, and mediocre designs shipped because nobody wanted to be “negative.”

Great design critiques aren’t about being nice or being harsh. They’re structured conversations that improve designs through focused feedback on specific problems. Here’s what I’ve learned running hundreds of design reviews across multiple companies.

The Development Context: Why Most Critiques Fail

The Fundamental Problem: Opinions Disguised as Feedback

Bad critique: “I don’t like this colour.” It’s an opinion with no context. The designer can’t act on it because there’s no connection to a problem or goal.

Good critique: “This colour has insufficient contrast with the background. Users with visual impairments won’t be able to read it, which conflicts with our accessibility guidelines.” This identifies a specific problem tied to user needs and company standards.

The shift from “I like/don’t like” to “this works/doesn’t work for these users because…” transforms critiques from taste discussions into problem-solving sessions.

Setting Context: What Are We Critiquing and Why?

Most failed critiques lack context. The designer presents work, and reviewers start commenting without understanding what problem the design solves, what constraints exist, or what stage the work is in.

Before showing designs, establish:

The problem: What user need or business goal does this address?

The context: What are the constraints? Technical limitations, timeline, design system rules, accessibility requirements?

The stage: Is this early exploration (many ideas, low fidelity), refinement (narrowing options), or polish (details matter)?

The ask: What specific feedback do you need? “Overall thoughts” is too vague. “Does this onboarding flow reduce the steps compared to our current version?” is specific.

Implementation Approach: Running Effective Critiques

Structure That Promotes Good Feedback

Free-form discussion rarely produces useful feedback. Structure the session:

1. Context setting (5 min): Designer presents the problem, constraints, stage, and specific questions. No feedback yet—just clarification questions to ensure everyone understands.

2. Silent review (5 min): Everyone reviews the designs silently, taking notes. This prevents the first speaker from anchoring everyone’s opinion. Designers learn to be comfortable with silence.

3. Structured feedback (20 min): Round-robin feedback tied to the designer’s specific questions first, then broader observations. No debates yet—just capture all perspectives.

4. Discussion (10 min): Now discuss conflicting viewpoints, explore alternatives, identify next steps. The designer drives this conversation, not the loudest voice in the room.

5. Summary (5 min): Designer summarises what they heard and what they’ll do next. This confirms understanding and creates accountability.

This structure ensures quieter voices get heard, prevents rambling discussions, and produces actionable outcomes. Total time: 45 minutes for meaningful critique versus 90 minutes of unstructured meandering.

The Role of the Designer: Active Participant, Not Passive Receiver

Bad pattern: Designer presents work, sits quietly while everyone comments, thanks people, leaves.

Good pattern: Designer sets context, guides the discussion, asks follow-up questions, challenges feedback when appropriate, and summarises decisions.

The designer shouldn’t be a passive recipient of feedback. They know the problem more deeply than anyone in the room. They should actively participate:

Ask probing questions: “You mentioned the navigation is confusing. Can you explain what you expected to find and where?”

Provide rationale: “I considered that approach but chose this one because of X constraint. Does that make sense, or is there a way to address the constraint differently?”

Challenge vague feedback: “When you say it doesn’t feel right, can you identify a specific element or user task that’s problematic?”

Drive decisions: “I’m hearing two opposing views on the information hierarchy. Given our user research showing users prioritise X over Y, I’m going to go with the first approach. Any concerns?”

This isn’t defensive — it’s collaborative problem-solving. The designer actively works with reviewers to improve the design rather than passively accepting all feedback.

Creating Psychological Safety

Harsh critiques don’t produce better designs — they produce defensive designers who stop taking risks. But overly gentle critiques that avoid honest feedback are equally harmful.

The balance is direct feedback on work, not on people:

Bad: “This looks amateur.” (Attacks the designer)

Good: “The alignment is inconsistent across these elements, which makes the interface feel unpolished.” (Specific, actionable feedback on the work)

Bad: “Did you even look at the design system before creating this?” (Assumes incompetence)

Good: “I notice this uses custom spacing instead of design system tokens. Was that intentional, or should we align with the system?” (Assumes competence, seeks understanding)

The goal is making feedback safe to give and receive. Psychological safety doesn’t mean avoiding hard conversations — it means trusting that feedback is given to help, not harm.

Scaling What Works: Growing the Practice

Making Critiques Routine, Not Special

When critiques are rare events, they become high-stakes. Designers stress about presenting. Reviewers over-invest in having opinions. The pressure creates worse outcomes.

Make critiques routine. Weekly design reviews where anyone can share work at any stage. This normalises feedback as part of the process, not a judgement event.

Cross-Functional Participation: Who Should Attend?

Should engineers attend design critiques? PMs? Only designers?

My experience: include people from adjacent disciplines, but set expectations. Engineers and PMs attend to understand the design and flag technical or business constraints, not to debate aesthetic choices.

Set ground rules:

• Designers lead and make design decisions
• Engineers flag technical constraints or implementation questions
• PMs flag business requirements or user needs that might be misaligned
• Everyone can ask clarifying questions
• Nobody debates taste

This cross-functional participation surfaces problems early (before designs are fully specced) while respecting domain expertise. Engineers catch technical impossibilities before designers invest heavily. PMs surface user needs that weren’t evident. But final design decisions rest with designers.

Teaching Critique Skills: Not Everyone Knows How

Giving good feedback is a skill, not an innate talent. New team members often struggle to provide useful critique. They either say nothing (too tentative) or nitpick irrelevant details (misunderstanding what matters).

Teach critique explicitly:

Good feedback is specific: Not “this feels off” but “the button placement requires users to scroll to find it, which adds friction to the primary action.”

Good feedback is tied to goals: Not “I prefer larger text” but “this text size might be hard to read for our older demographic, which could reduce conversion.”

Good feedback acknowledges trade-offs: Not “add more features” but “expanding features here might increase complexity—is that trade-off worth it for this use case?”

Key Takeaways

Great design critiques require:

• Frame feedback as problems, not preferences - “I don’t like” is opinion; “Users will struggle because” is actionable feedback. Tie all critique to user needs or business goals.
• Establish context before showing work - What problem does this solve? What constraints exist? What stage is it in? What feedback do you need? Context prevents wasted critique.
• Use structure to improve quality - Silent review, structured feedback, then discussion. This format surfaces better insights in less time than unstructured conversation.
• Designer leads the critique - The designer isn’t a passive recipient. They guide discussion, challenge vague feedback, and drive decisions based on what they hear.
• Make critiques routine and safe - Frequent, low-stakes reviews normalise feedback. Psychological safety means direct feedback on work with trust in positive intent.

Closing Thoughts

The best design teams I’ve worked with don’t have the most talented designers, they have the strongest critique culture. Designs improve through iteration, and iteration requires honest, frequent feedback.

That feedback isn’t about who has the strongest opinion or the most senior title. It’s about collaborative problem-solving where everyone contributes perspectives, but the designer synthesises those perspectives into better solutions.

If your design critiques feel contentious, opinion-driven, or result in designers avoiding feedback, the problem isn’t the people—it’s the structure and culture. Fix those, and you’ll be surprised how quickly designs improve.

Start with one thing: before the next design review, establish clear context and specific questions. That single change will make the session 10x more useful. Build from there.

Have questions or thoughts? Get in touch - I’d love to hear from you!