Design Critique Frameworks
Design critiques are structured conversations about work-in-progress designs. A designer presents work and receives feedback from peers and leaders. Critiques help catch problems before projects advance and expose assumptions needing testing. Unstructured critiques often devolve into preference battles–I like blue, you like green. Structured frameworks keep conversations focused on goals and user needs. They distinguish between aesthetic preferences and functional issues. A framework creates shared expectations about what critique is for and how to participate productively. Good critiques accelerate learning; bad ones waste time and discourage designers. Frameworks tilt critiques toward the former.
Common Frameworks
The “I like, I wish, I wonder” framework invites three types of feedback. I like–what works well–builds confidence. I wish–what could improve–surfaces problems. I wonder–what if questions–spark exploration. This framework balances positive and constructive feedback. Asking “I wonder if using bigger type would make this clearer” is gentler and more generative than “the type is too small.” Audience-centred critique focuses on specific user personas and contexts. Rather than generic feedback, critique references the actual user: “Sarah is a busy parent; will she understand this within two seconds?” Intent-based critique asks the designer to state their goal first. “I am trying to reduce checkout friction” focuses discussion on whether the design achieves that goal rather than debating visual choices. Design debt reviews focus on feasibility and maintenance burden. “How will this pattern scale if we add more items to the list?”
Running Effective Critiques
a structured method for comparative design audits
Prepare before the meeting–designers present work and communicate the goal and constraints. Allocate time proportional to design maturity: five minutes for early sketches, thirty minutes for high-fidelity work. Ensure diverse perspectives–different roles (engineering, product, support) catch different issues. Establish psychological safety; harsh or personal criticism kills engagement. Distinguish between “this does not meet the goal” (valid critique) and “this is not my taste” (preference). Document feedback rather than discussing everything in real-time. Synthesis after the meeting is easier than trying to act on scattered verbal feedback. The designer should leave understanding what feedback is actionable and what was merely opinion.
Integrating Feedback
Feedback does not mean doing everything everyone suggests. The designer synthesises input and makes decisions. Contradictory feedback is common; the designer interprets it in light of goals and data. If critique suggests two opposing directions, testing with users breaks the tie rather than arguing. Over-relying on critique can lead to design by committee–everything feels like a compromise. Critique is input, not decision-making. Regular critiques throughout a project maintain alignment. One critique at the end when major changes are impractical frustrates everyone. Critiques at sketching, wireframing, and high-fidelity stages let teams course-correct progressively. Documenting critiques and resolutions helps future teams learn. Why was that approach chosen over alternatives? Critique records preserve that thinking.