Design critique

Why it matters

Designers never work alone for long. Product managers, developers, other designers, and sometimes clients all look at the work and react. Unstructured reactions ("I don't love it", "make it pop") are frustrating and rarely improve anything. A design critique is a structured conversation that tests a design against its goals, so the work gets better and nobody's feelings get trampled. Being good at critique, both giving and receiving, is one of the clearest signs of a professional designer, and it matters just as much for developers and game designers who review each other's work.

Critique is not approval and not taste

A critique is not a vote on whether people like the design, and it is not the moment a manager signs it off. It answers one question: does this design achieve its goals for its users, and what would make it better?

That means every critique needs the goals on the table first. "This button is too small" is an opinion. "The goal is that first-time users find Register in under five seconds, and this button is the same colour as the body text, so it might be missed" is useful feedback linked to a goal.

Roles in a critique

• Presenter (the designer): explains the context, the goals, the constraints and what kind of feedback they want.
• Reviewers: give feedback tied to the goals.
• Facilitator: keeps time, keeps the discussion on goals, and makes sure everyone speaks. In a small group the presenter can facilitate.
• Note-taker: captures feedback so the presenter can listen instead of writing. It can be one of the reviewers.

A simple format (30 minutes)

1. Context (5 min). The presenter states: who the users are, the problem, the goals or success measures, constraints (time, technology, brand), what stage this is (early sketch or nearly final), and the specific questions they want answered. Early sketches deserve big-picture feedback; near-final designs deserve detail.
2. Silent review (5 min). Reviewers look at the design and write notes privately. This stops the loudest person from setting the agenda.
3. Discussion (15 min). Reviewers share, one point at a time, starting with the presenter's questions.
4. Wrap-up (5 min). The presenter summarises what they heard and what they will do next. They do not have to accept every point.

Giving good feedback

A useful pattern is observation, effect, goal:

Observation: The price is in the same small grey text as the description.
Effect:      I had to search for it; I found the button before the price.
Goal link:   The brief says people should compare plans quickly.
Question:    What if the price were the largest element on each plan card?

Other tips:

• Start with what works, specifically. "The step numbers make the sign-up flow feel short" helps the designer know what to keep.
• Describe problems, not solutions. Offer ideas as questions ("What if...?"), because the designer may know constraints you do not.
• Be specific. Point at the exact element and say what happened when you looked at it.
• Separate your taste from user needs. If it is only a preference, say so.
• Critique the work, not the person. "This layout" not "you".

Receiving feedback well

• Listen first, then ask clarifying questions. "Can you say more about where you got stuck?"
• Do not defend every decision in the moment. Note it, then decide later.
• Look for patterns. If three people mention the same area, take it seriously even if their suggested fixes differ.
• Close the loop. Afterwards, share what you changed and why you did not change other things.

Remote and async critique

Teams spread across time zones often critique in comments. In Figma, reviewers can pin comments to exact spots. The same rules apply: the designer posts context and questions first; reviewers write observation, effect and goal; the designer replies and resolves comments when handled.

Common mistakes

• No goals presented, so feedback becomes taste.
• Jumping straight to solutions ("make it blue").
• Pixel-level comments on a rough sketch, or big rethinks on a design shipping tomorrow.
• The designer arguing every point instead of listening.

Quick recap

• Critique tests a design against its goals; it is not approval or a taste vote.
• The presenter gives context, stage and questions; reviewers review silently, then discuss.
• Feedback pattern: observation, effect, goal, then a question.
• Receive feedback by listening, looking for patterns and closing the loop.

Try it

Open the Do tab and run a 30-minute critique of one of your designs from this course with two or three people.