How to Run a Design Critique That Ends in Decisions

Decide what the critique can change

Define a question narrow enough to answer in the session. “Can a first-time visitor understand the booking options?” is more useful than “Thoughts on the new website?”. State the audience, task, stage of work, known constraints and what is outside the discussion. A critique of hierarchy should not unexpectedly become an approval meeting about the product strategy.

Nielsen Norman Group defines critique around whether a design meets its objectives and emphasizes a clear scope, agreed goals and conversation rather than commands. Its guidance distinguishes standalone critiques from reviews aimed at approval. Use that distinction in your invitation so participants know whether they are improving a proposal or making a release decision.[1]

Designlab’s critique guide distinguishes useful questions and discussion from a hostile evaluation of the person doing the work. Keep the invitation focused on the design question and make room to explain the constraints.[3]

A half-hour agenda you can actually facilitate

Use this suggested agenda for one bounded question: five minutes to frame the task and constraints, five for quiet observation, ten for discussion, five to decide what changes or needs a test, and five to assign the follow-up. Adjust the timing to the complexity. The value lies in protecting observation and closure, not in treating thirty minutes as a universal research finding.

Send the work beforehand with the question and a short route through it. Show the relevant task in the meeting rather than touring every screen. Ask people to note observations before hearing the presenter’s full explanation; otherwise they may judge the story they were told rather than the interface the user will encounter.

The illustrated route is Frame → Observe → Question → Decide → Assign. Put those same headings in the notes. If the discussion consumes the decision time, stop and name what remains open. A shorter session with explicit unknowns is more useful than a longer conversation whose apparent agreement cannot be reconstructed.

Invite for perspective, and name the decision owner

Choose people because they can expose a relevant risk or explain a constraint: a developer for feasibility, a support colleague for recurring problems, a content designer for wording, or another designer for an alternative reading. Keep participation small enough that each person can contribute to the actual question. Avoid adding attendees solely to create a sense of consensus.

Assign a facilitator and a recorder. They can be the same person in a small group, but make the responsibility visible. Identify who can make the eventual decision and what evidence they will use. If that person cannot attend, the group can still critique the work; it should not invent approval authority.

NN/g describes round-robin participation, timeboxing, reformulating opinionated feedback, documenting the discussion and following up as facilitation practices. Use those practices to make room for relevant perspectives, especially when one senior voice would otherwise define the conversation.[1]

Ask questions that connect an observation to the task

Use a simple ladder: What do you notice? What does that imply for the task? What supports that interpretation? What would distinguish the possible explanations? This lets the group separate an observed detail from a predicted user response. “The action is below three equally strong cards” is an observation; “people will abandon” is a prediction that needs evidence.

Replace “I don’t like the color” with “Which element should lead, and is this treatment giving it that priority?”. Replace “Make this a modal” with “What problem are we trying to solve, and what alternatives preserve the task?”. A proposed fix is welcome, but it should not erase the problem statement before the team understands it.

Keep a small set of prompts visible: Can the person identify the next action? Is the information needed for that action present? What happens when the task cannot complete? Which part is supported by evidence, and which part is our assumption? Use the questions that fit; do not turn the session into a ritual of asking all of them.

Handle taste, tension and the senior-person verdict

Aesthetic preference can be useful input when the question is visual direction. Label it as preference and connect it to the agreed direction. If the question is whether an error is understandable, preference has less authority than the actual wording and an appropriate usability check. The Task and Taste illustration shows two kinds of contribution, not two kinds of person.

When someone says “Just do it this way”, ask what constraint or objective makes that choice necessary. If the answer is a business decision, record it as such. If it is a prediction about users, record the assumption and the test that could resolve it. Do not manufacture a user-research conclusion from a senior stakeholder’s confidence.

Protect the presenter from defending every detail while still making room for context. A useful facilitation line is: “Let’s record the concern first, then hear the constraint behind the current choice.” This keeps the conversation about a shared problem rather than a contest between the person who designed it and the person commenting.

A checkout critique, closed with a usable record

Suppose the question is whether a first-time buyer can choose collection or delivery before payment. The group observes that delivery cost appears only after address entry. It considers showing an estimate earlier, adding an explanation, or leaving the sequence unchanged. The concern is uncertainty about total cost; moving a control is only one possible response.

Close with a precise outcome: “Explore an earlier cost explanation. Designer owns two copy treatments; engineer confirms what can be calculated before address entry; the team will inspect both against the full checkout task.” Keep the current decision and the remaining test separate. Do not record “checkout fixed” when the group has only agreed to investigate.

Use a design decision log for choices that need to survive beyond the meeting. Link the work version, alternatives, reason and reopen condition. For a detailed state review, the UI state reference checklist can supply the missing failure and recovery questions without expanding every critique into a complete audit.

Make asynchronous critique equally specific

Give asynchronous reviewers the same task, question, version and response deadline. Ask them to identify the location, observation, effect on the task and suggested next step. Consolidate duplicate comments, separate decisions from questions and tell contributors what happened to their feedback. Silence is not evidence that a design was understood or approved.

Keep reference examples beside their source and the reason they matter. The annotation guide helps distinguish observation from interpretation. Explore Sesavu for the current public collection surface and consult its documentation for present availability; the critique notes can be maintained in any shared document.