A review that produces better design decisions — not just better feelings.

Design critique is a structured review of design work against stated goals, user needs, and design principles — with the explicit purpose of improving the work. It's not a session where designs get approved. It's not a forum for personal preferences. It's a process for finding what's working, what isn't, and what needs to change before the work moves forward.

The distinction matters because most "design reviews" in practice are one of two things: approval meetings where stakeholders decide whether they like it, or informal feedback sessions that produce contradictory suggestions with no clear resolution. Neither is critique.

These happen at different stages and serve different purposes:

Critique happens while the work is still being shaped. The question is: does this solve the problem? It's evaluative and structured.

Feedback is more informal — a reaction, an observation, a suggestion. It's input, not a decision, and it happens throughout the design process.

Approval is a gate at the end. It's not a conversation.

Treating approval meetings as critique sessions is one of the most common causes of late-stage design changes that could have been caught weeks earlier. The cost of changing a decision in a critique is a conversation. The cost of changing it after stakeholder sign-off is a week of rework.

A productive critique has a few consistent elements:

Presenter sets context first. Before showing anything: what problem is this solving, who is it for, what constraints exist, and what specific feedback is needed? Without this framing, reviewers respond to what they see rather than what the work is trying to accomplish.

Questions before opinions. Reviewers ask clarifying questions before offering judgments. "What happens if the user skips this step?" surfaces different insight than "I don't think this will work."

Feedback references the brief. "This doesn't seem to address the navigation problem we saw in research" is actionable. "I'd make this bigger" is a preference. Teams that can't tell the difference have a critique culture problem.

One person captures decisions. Without a written record of what was agreed, the same conversations repeat in the next session.

The most senior person speaks first. Everyone else then responds to their view rather than the work. Run the first round silently — individual reactions noted before sharing — and have senior input come last.

No stated goals. If the brief wasn't clear before the critique, the work can't be evaluated against it. Designers who haven't internalized the problem they're solving can't defend their decisions when challenged.

Preference masquerading as critique. "I just don't love this" is not an evaluation. If reviewers consistently give preference-based feedback, the team doesn't have a critique culture — it has a taste contest. Redirecting to the brief every time this happens is the only reliable fix.

Critique works best as a standing rhythm, not a pre-launch checkpoint. Weekly or bi-weekly sessions with consistent participation build the shared vocabulary and trust that makes feedback land well and get acted on.

Teams that run regular critique tend to ship fewer late-stage surprises, build stronger cross-functional alignment, and develop a more coherent shared understanding of the Design Principles that govern their product. The investment is low — one to two hours a week. The payoff shows up in fewer revision cycles, earlier problem detection, and design decisions that don't need to be relitigated at every stakeholder review.