Design Critique: Facilitate Feedback That Improves the Work
Design critique can help teams catch problems early, share context, and improve an evolving idea. It can also turn into a meeting of personal preferences, stakeholder approval, or a list of instructions that leaves the designer unsure what problem to solve.
A useful critique has a defined purpose: analyze whether the work meets its objectives and identify opportunities to improve it.
Set the scope before inviting feedback
Tell participants what they are reviewing and what is not in scope. Is the team discussing a user flow, information hierarchy, interaction behavior, or visual polish? A precise scope helps people give feedback that the presenter can act on.
Share the user problem, relevant research, design constraints, and questions before the meeting. Without this context, participants may evaluate the screens against their own assumptions rather than the intended user need.
Distinguish a critique from a design review or approval meeting. If a decision-maker must approve a release, make that a separate, explicit purpose instead of combining approval with an exploratory feedback session.
Facilitate around objectives, not taste
Start with the presenter explaining the goal and the questions they want help with. Invite participants to describe what they notice, what they expect, and where the design may fail a stated objective.
When feedback sounds subjective—“I don't like this” or “make the button bigger”—ask what user need, task, or evidence the suggestion relates to. It may uncover a valid concern, but the proposed solution is a hypothesis, not a requirement.
Keep the discussion conversational. A critique is not a command channel where the most senior person assigns pixel changes. Encourage clarifying questions and alternative interpretations, especially when research evidence is incomplete.
Include the right people and the right artifact
Invite people who bring relevant perspectives: design, engineering, research, content, accessibility, product, or operations depending on the question. More attendees are not automatically better; large groups can make feedback harder to prioritize.
Show enough of the journey for participants to understand the interaction. A single polished screen may hide the state before it, the error path, or what happens after a user acts. For an early concept, make its fidelity clear so participants do not focus on details that are not yet being decided.
Capture feedback without turning it into a vote
Record observations and questions separately from suggested solutions. Group feedback by user task or objective, then decide which items need evidence, a prototype, a design change, or no action.
The presenter remains responsible for the design decision in context. A critique can reveal a risk the presenter did not see, but it does not make every suggestion equally valid. Link decisions to user evidence, product constraints, and the goals of the work.
Close the loop after the session
Share what changed, what did not, and why. If a concern is deferred, document the reason and when it may be revisited. Following up helps participants see that critique is part of iterative work rather than a meeting that consumes time without affecting the outcome.
For team contribution and workflow practices, see the DesignOps guide and design-system governance guide.