Design Critiques: Test the Decision, Not the Designer

A critique begins badly when the first slide says, “Here is the new onboarding.” The room has been shown an object, not a decision.

People can only react to what they see, so colour preferences, copy edits, and solution pitches rush in to fill the vacuum.

The useful unit of critique is a design decision and the evidence behind it. The screen or prototype is merely the current expression of that decision.

That distinction changes the meeting. It gives reviewers something more demanding than taste to discuss and gives the designer a reasoned basis for accepting, rejecting, or investigating feedback.

Put one consequential decision on the table

Before inviting reviewers, write a short critique brief. It should be understandable without a presentation and answer five questions:

1. What decision is open? Name the choice the work makes.
2. What user behaviour or need matters? Cite the evidence, not a generic persona.
3. What risk could make the decision wrong? Include product, technical, operational, and exclusion risks where relevant.
4. What is fixed for now? State constraints and decisions outside this critique.
5. What should the critique produce? Ask for a challenge, comparison, missing state, or evidence gap—not “thoughts.”

“Critique the checkout” is not a brief. “Does moving account creation after payment reduce interruption without making order recovery unsafe?” is one. It identifies a decision, a desired effect, and a risk worth examining.

Do not bundle unrelated questions to make the meeting feel efficient. Navigation hierarchy, empty-state copy, payment recovery, and visual identity demand different evidence and often different reviewers.

One broad review tends to resolve whichever issue is easiest to notice.

Choose participants from the risk. An engineer can expose a state transition the prototype hides. Support can identify a recovery path users actually need. A researcher can distinguish an observed pattern from a convenient interpretation.

Seniority alone is not relevant expertise. A leader who owns the commercial constraint may belong in the room; a leader attending because every design needs executive approval probably does not.

Inspect before the room converges

Begin with a quiet inspection of the brief and artefact. Ask each reviewer to record what they observed before anyone advocates a conclusion.

This is not ceremony. In Stasser and Titus’s political-caucus simulation, discussion over-sampled information members already shared and information consistent with their initial preferences.

The setting was artificial, not a product critique, so it does not prove a facilitation recipe.

A cautious inference for critique is to record distinct observations before open discussion, because information held in common may otherwise dominate what the group examines.

During the inspection, use a simple feedback form:

• Observation: what is present, absent, or implied in the artefact;
• Risk: what may happen, for whom, and under what condition;
• Evidence: what supports the concern, or what remains unknown;
• Question or test: what could discriminate between plausible explanations.

“The secondary action looks weak” is a reaction.

“On the confirmation screen, cancel and edit use the same weight; could a hurried user mistake one for the recovery path?” is a reviewable risk. It can be checked against hierarchy, task evidence, and a prototype test.

The form is a discipline, not a script. A reviewer does not need evidence for every novel concern. They do need to label an intuition as an intuition rather than laundering it into a user fact.

Make the critique a contest between explanations

After the silent scan, restate the decision and invite reviewers to contribute their strongest distinct observation. Capture observations before debating solutions.

Then group them by the assumption they challenge. Several comments about labels, sequence, and confirmation may all point to one deeper question: does the design make the system state legible?

For each material challenge, ask:

• What would have to be true for the current design to work?
• What evidence supports that belief?
• What alternative explanation fits the same evidence?
• What is the cost of being wrong?
• What is the cheapest credible way to reduce the uncertainty?

The prototype walkthrough studied by Hundhausen, Fairbrother, and Petre offers useful but bounded evidence.

Across video analysis of 16 walkthroughs in two university HCI courses, students discussed relevant design issues and justified more than 80% of design statements and critiques.

Nearly a quarter of those justifications referred to theoretical or empirical bases. That is evidence from an educational setting, not proof that walkthroughs improve commercial outcomes.

Its practical lesson is narrower: asking reviewers to expose their reasoning makes the intellectual quality of critique observable.

Do not vote on competing explanations. A majority can still share the same unsupported assumption. The decision owner should judge the evidence and risk, then choose one of four dispositions:

• change now because the critique exposed a supported flaw;
• test because the alternatives remain plausible and the decision is consequential;
• accept the risk because the likely cost does not justify more work;
• decline because the feedback is outside scope, contradicted by stronger evidence, or based on preference.

Record the reason. “No change” is a legitimate result when the argument survives examination.

Keep status from becoming evidence

Inviting a range of roles does not make their information equally likely to be heard. A staff designer may frame the problem before a junior engineer names the state the design cannot support.

A product director’s preference may quietly become the team’s requirement.

Nembhard and Edmondson studied survey data from 23 neonatal intensive-care units engaged in quality-improvement work.

In that healthcare context, perceived leader inclusiveness—words and actions that invited and appreciated contributions—was associated with psychological safety.

It also moderated the relationship between professional status and psychological safety.

The study was field research in clinical teams, not a controlled design-critique experiment. It supports taking hierarchy seriously; it does not guarantee that one facilitation technique creates safety.

Useful safeguards are deliberately mundane:

• let people inspect and write before leaders speak;
• ask the person with the most relevant evidence, not the highest title, to explain it;
• require leaders to distinguish a constraint from a preference;
• let the designer question feedback without being labelled defensive;
• assign the final disposition to a named decision owner.

Psychological safety does not mean frictionless agreement. A critique without disagreement may simply be a room in which the cost of speaking is unclear.

Know what critique cannot certify

A critique can reveal assumptions, compare interpretations, and identify evidence gaps. It cannot substitute for every method that should follow.

It is not user research. Colleagues predicting user behaviour remain colleagues predicting user behaviour.

When uncertainty concerns comprehension or action, use an appropriate prototype and evidence plan.

It is not an accessibility conformance evaluation. W3C notes that no tool alone can determine accessibility and that knowledgeable human evaluation is required.

Critique can surface exclusion risks, but standards-based checks and evaluation with disabled people do different work.

It is not a technical design review. An engineer in the room can reveal constraints, but production states, failure handling, security, data, and performance still need explicit verification.

It is not approval. If the organisation requires approval, name the approver, criteria, and authority separately. Hiding sign-off inside “feedback” makes both the critique and governance dishonest.

It is not a design handoff. Critique tests the reasoning before or during design; handoff keeps accepted intent executable through implementation.

Close the loop with a decision record

Critique notes often become a graveyard of comments. Replace the transcript with a compact decision record:

Field	What to capture
Decision	The choice that was examined
Evidence	What the team relied on and where it is stored
Material risks	The challenges worth acting on
Disposition	Change, test, accept, or decline
Owner and date	Who closes the next step and when
Revisit trigger	New evidence or condition that reopens the decision

This record should travel with the work. If the decision changes in implementation, the team can see whether a constraint invalidated the reasoning or the intent was simply lost.

That is the bridge to design and engineering collaboration.

Consider a fictional example. A team designing invoice approval believes that showing all policy exceptions inline will help approvers make a confident decision.

Operations warns that some exceptions depend on evidence loaded later from another system.

The critique does not end with “simplify the screen.” It records the assumption that exception data is complete at review time and marks the current design unsafe when data is late.

The team commissions a prototype of explicit pending and unavailable states.

The valuable output is not prettier work. It is a hidden condition made visible before code turns it into product behaviour.

A critique is successful when the reasoning gets sharper

Do not judge a critique by the number of comments, the warmth of the room, or whether the artefact changed.

Judge it by whether the team can now state the decision, its strongest support, its most consequential uncertainty, and what happens next.

Good critique protects design authorship without protecting weak reasoning. It gives reviewers influence without pretending every opinion is evidence. And it lets a product team disagree before implementation makes disagreement expensive.

Sources

• Bardzell, J., & Bardzell, S. (2008). Interaction criticism: a proposal and framework for a new discipline of HCI. CHI ‘08. A conceptual framework for rigorous, evidence-based interpretation of interfaces; it is not an outcome study of critique meetings.
• Hundhausen, C. D., Fairbrother, D., & Petre, M. (2012). An empirical study of the “prototype walkthrough”: a studio-based activity for HCI education. ACM Transactions on Computer-Human Interaction, 19(4), Article 26.
• Stasser, G., & Titus, W. (1985). Pooling of unshared information in group decision making: Biased information sampling during discussion. Journal of Personality and Social Psychology, 48(6), 1467–1478.
• Nembhard, I. M., & Edmondson, A. C. (2006). Making it safe: The effects of leader inclusiveness and professional status on psychological safety and improvement efforts in health care teams. Journal of Organizational Behavior, 27(7), 941–966.
• W3C Web Accessibility Initiative. Evaluating Web Accessibility Overview. Guidance on standards-based evaluation, human review, tools, and involving disabled users.

Read next

• Rapid Prototyping: Build the Evidence, Not the Product
• Inclusive Design: Make Exclusion a Product Decision
• Design Handoffs: Build a Shared Verification System
• Design and Engineering Collaboration: Keep Intent Executable