Home: Mohammad Abu-aishehOpen to work Open to work العربية

Process & product // Guide

Running a useful design critique

A good critique improves the work toward its goals. Learn how to set goals, structure feedback, avoid solutioning and handle feedback well.

Running a useful design critique

What a critique is for

The purpose of a critique is to improve the work so it better meets its goals. It is not a vote on taste, an approval meeting or a judgement of the designer. Comments are useful when they connect to a goal, a user need or a constraint.

How to run the session

  1. Restate the goals first. Share the problem, the audience, the constraints and the kind of feedback needed (for example, layout rather than colour).
  2. Name one facilitator. This person keeps the focus, shares the time fairly and stops side debates.
  3. Set a timebox. A fixed time, with some of it reserved for silent note-taking, keeps the session productive.
  4. Capture actions and owners. End by listing what will change, who does it and by when.

Give better feedback

Feedback frames add structure. One simple frame uses three openers:

  • I like…

    “I like that the price is the first thing I see.”

  • I wish…

    “I wish the cancel option were easier to find.”

  • What if…

    “What if the steps were shown as a progress bar?”

  • Critique the design, not the designer: say “the button label is unclear”, not “you labelled it badly”.
  • Tie comments to goals and users: “A first-time visitor may not understand this term.”
  • Avoid solutioning in the room. Name the problem and let the designer explore options afterwards.

How to receive feedback

  • Listen first and take notes instead of defending the work.
  • Ask clarifying questions, such as “Which goal does that affect?”
  • Separate the comments into those you will act on, those you will test and those you will set aside, and say why.

A critique succeeds when the work gets closer to its goals, not when everyone agrees.

Keeping the room productive

Critiques go wrong in familiar ways. A few ground rules prevent most of them.

  • Invite the right people. A small group with relevant knowledge works better than a crowd.
  • Give everyone a turn. Collect written comments first so quieter people are heard.
  • Park off-topic points. Write them on a separate list instead of debating them.
  • Be specific. “This is confusing” is weak; “The two buttons look equally important” is something to act on.

Follow up after the session by sharing the notes and the agreed actions, so the discussion leads to changes.

This guide was drafted with AI assistance from public standards and references. For the exact wording of a standard, use the sources listed above.

More on this topic

  • Process & product2 min read

    A design handoff checklist for developers

    A good handoff covers every state, responsive behaviour, tokens, assets, motion, accessibility, content rules and edge cases, then a review of the built result.

  • Process & product2 min read

    Design system basics: where to start

    A design system is tokens, components, patterns and documentation. Start with an audit, begin small, name things clearly, and measure adoption.

  • Process & product2 min read

    How to write a UX case study

    A strong case study has a clear structure, separates your work from the team’s, is honest about gaps, never invents metrics, and respects a hiring manager’s time.

Keyboard shortcuts
Single-key shortcuts

Turn off if you use speech input or find them getting in the way.