Design critique is where teams build or lose psychological safety. A designer presents work they have spent days or weeks developing. The team responds. If the response is structured, specific, and respectful of the designer's expertise, the designer takes bigger creative risks next time. If the response is a round of personal preferences delivered as authority, the designer learns to play it safe. Over time, the quality of the critique determines the quality of the work.
This is not a soft claim. Harvard professor Amy Edmondson's research on psychological safety, based on studies across healthcare, technology, and manufacturing, found that psychological safety is the strongest predictor of team effectiveness. Google's Project Aristotle confirmed this: across 180 teams, psychological safety was the number one factor distinguishing high-performing teams from average ones. Design critique is one of the most frequent and visible places where safety is tested.
The problem is that most design critiques default to one of two failure modes: the free-for-all (everyone shares their personal preference and the loudest voice wins) or the rubber stamp (everyone says it looks great and nothing improves). Neither produces good design or good teams.
What Makes Critique Different From Review
The first structural problem is that most teams conflate critique and review. A design critique happens during the design process. The work is in progress. The goal is to improve it. A design review happens closer to completion. The goal is to decide whether the work is ready to ship.
Conflating the two produces two specific failures. Early-stage work gets evaluated as if it were finished, which kills concepts before they mature. Late-stage work gets treated as if there is still time to explore, which produces scope creep and missed deadlines. Separating critique from review gives the team permission to be exploratory during critique and rigorous during review.
The Liz Lerman Critical Response Process
Liz Lerman's Critical Response Process (CRP), devised in 1990, is the most structured creative feedback method available. Originally designed for dance critique, it has been adopted by design teams, writing workshops, and a security team at Google. The process has four steps.
Step 1: Statements of meaning. Responders share what was meaningful, evocative, interesting, or striking in the work. This is diagnostic, not polite. It tells the designer which parts of the work are landing as intended.
Step 2: Artist asks questions. The designer asks the responders whatever they want to know. This puts the designer in control of the conversation's direction.
Step 3: Neutral questions. Responders ask questions without embedded opinions. "What was your intention with the navigation placement?" rather than "Why is the navigation buried?" The neutral framing invites explanation rather than defense.
Step 4: Opinions by permission. Responders offer opinions only on topics the designer wants feedback on. "Would you like my thoughts on the typography?" If the answer is no, the responder moves on. Purdue's writing program has documented that this structure leaves creators motivated to continue working rather than deflated.
The "I Like, I Wish, What If" Framework
Stanford d.school developed the "I Like, I Wish, What If" framework as a simpler alternative for contexts where the full CRP feels too formal. It works especially well when non-designers are participating in the critique.
"I like..." identifies what is working. "I like how the onboarding flow reduces the number of decisions to one per screen." This is specific and descriptive, not generic praise.
"I wish..." identifies what could improve. "I wish the error states were as clear as the success states." This frames the feedback as a desire rather than a demand.
"What if..." opens exploration. "What if the empty state included a suggested first action?" This invites possibility rather than prescribing a solution.
The framework works because it structures feedback as I-statements rather than directives. "I wish the hierarchy were clearer" lands differently than "The hierarchy is wrong." The d.school explicitly recommends this format because feedback is best given in I-statements, which reduces defensiveness and increases the signal-to-noise ratio. For more on how to deliver constructive criticism across contexts, see how to give constructive criticism.
How to Critique When You Are Not a Designer
Non-designers give design feedback constantly. Product managers, engineers, executives, and marketers all have opinions about design. The problem is that they express those opinions as visual prescriptions: "Make the logo bigger." "Try a different blue." "Can we add more whitespace?" These prescriptions bypass the designer's expertise and turn the critique into a game of telephone where the designer implements someone else's visual instincts.
Non-designers give better feedback when they focus on three things.
Describe the problem, not the solution. "I am not sure the primary call-to-action is visible enough" describes a problem. "Make the button bigger and red" prescribes a solution. The designer can solve the visibility problem in ways the non-designer has not considered.
Reference the user, not your preference. "A first-time user might not understand what to do on this screen" is useful feedback grounded in user experience. "I do not like the layout" is personal preference that gives the designer no useful information.
Ask questions before making statements. "What was the thinking behind the two-column layout?" invites the designer to share their rationale. The rationale might change how you feel about the design. Or it might reveal a misalignment in goals that the question surfaces before it becomes a problem. For how these dynamics play out between designers and engineers specifically, see how to give feedback on creative work.
Receiving Critique Without Defensiveness
Giving good critique is half the skill. Receiving it is the other half. Designers who receive critique well create better feedback cultures because people are more willing to be candid when they know the designer will engage constructively.
Set the context before presenting. Tell the room what stage the work is in, what specific feedback you want, and what is not up for discussion. "This is an early exploration of the information architecture. I am looking for feedback on the navigation structure. The visual design is placeholder." This prevents the common failure mode where responders critique the visual design of a wireframe.
Write down the feedback before responding. The emotional response to critique fades faster than most people expect. Writing it down creates a buffer between hearing the feedback and deciding what to do about it.
Separate "I disagree" from "I feel attacked." These feel similar in the moment but are structurally different. Disagreement is productive. Feeling attacked shuts down cognition. If you notice the attacked feeling, name it internally and return to the feedback after the session. For more on why this skill is perishable and requires active maintenance, see psychological safety is a perishable skill.
Building a Critique Culture
The single most important factor in whether design critique produces value is consistency. Weekly critiques feel normal. Quarterly critiques feel like performance reviews. The cadence matters more than the format.
A few structural choices help. Rotate who presents. Rotate who facilitates. Time-box the session (45 to 60 minutes). Require at least one specific positive observation before any criticism. End with the designer summarizing what they heard and what they plan to do next. These are not rules for their own sake. They are guardrails that prevent the critique from collapsing into the free-for-all or the rubber stamp.
QuestWorks is the flight simulator for team dynamics. It runs teams through scenario-based quests on its own cinematic, voice-controlled platform where teammates practice giving and receiving feedback under pressure. Quest scenarios create situations that require the exact behaviors good critique demands: being candid without being destructive, listening to perspectives that differ from your own, and making decisions together when the answer is ambiguous. QuestDash surfaces behavioral patterns across the team. HeroGPT provides private AI coaching that never shares upstream. Participation is voluntary and never tied to performance reviews. QuestWorks works with Slack for install, onboarding, and admin. The game runs on QuestWorks' own platform. It starts at $20 per user per month with a 14-day free trial.
Design critique is a team skill. The teams that do it well produce better work because designers take bigger risks, non-designers contribute useful perspectives, and the feedback loop actually improves the output rather than diluting it. The teams that do it badly produce safe, committee-designed work where nobody is proud of the result and nobody knows how to fix the process. The difference is structure, practice, and the psychological safety to be candid without being cruel.
Try it free
