Design Critique
Practice
A session where designers examine a draft together by asking what it was meant to solve, rather than judging whether it is good.
Why it exists
For a long time there was one way for a designer to show finished work to anyone else: screenshot the screens, drop them in a chat channel, and wait. What came back was usually one of two things — a short "looks good," or a remark about the blue being a bit dull.
The trouble was that nobody could tell where those remarks came from. When a line like "the blue looks dated to me" appeared in the channel, its weight depended entirely on who typed it. From the founder, the color changed by the next morning. From an intern, nothing happened at all. The designer had no better footing. Explaining why the document list sits on the left means pulling up research from three weeks ago, and a chat channel is not the place for that conversation.
So two things were broken at once. Opinions arrived without reasons, and decisions arrived without explanations. A design critique is the format built to hold both in the same room. The person who made the work says first what problem the screen was meant to solve, and everyone else describes where they personally got stuck instead of what they personally like. Nothing gets approved here, and that is deliberate — once approval is the goal, people stop looking for what to fix and start looking for reasons to pass.
How it runs
Two or three drafts go into a one-hour session, and each draft moves through the same five steps.
- Context — the maker spends two or three minutes on what the screen is for. Not just the feature but the person and the moment: "someone on the free plan creating their twelfth document."
- Silent reading — three to five minutes with nobody talking while everyone looks and takes notes. This step exists so the first voice in the room doesn't decide where everyone else looks.
- Questions before opinions — facts get checked first. "How long can this list get?" About half the opinions in the room disappear at this step, because what looked like an oversight usually turns out to be a decision already made.
- Observations — people describe where they got stuck instead of proposing fixes. Not "this button is hard to see" but "on the checkout screen I couldn't find the next-step button within three seconds." The first version is an instruction. The second is raw material.
- Wrap-up — the maker writes down, right there, what they're taking and what they're leaving. Nothing obliges them to act on all of it. The person who made the work decides.
One person facilitates. They pull the conversation back to step 4 when it drifts into suggested solutions, and they cut in when one person has been talking for a while. Without that role, the session turns within twenty minutes into everyone describing the screen they would have drawn instead.
Who joins and when
Three or four designers doing similar work is the standard room. The condition that makes the format work is that nobody present has authority over the outcome. Put one person with that authority in the room and everyone else starts reading their face, and the session quietly becomes a design review.
Inviting one engineer buys something real: constraints surface while the work is still a drawing rather than after it's been built. A layout that needs data the product doesn't store yet is cheap to hear about now and expensive to hear about in the second week of implementation. Agree in advance that they're there to describe what's hard to build, not to approve anything.
Timing means while the work can still be thrown away. A wireframe — layout drawn as gray boxes with no color or type — is a good moment, and so is an early mockup once visual choices are on it. A critique two days before engineering starts is a screening, not a critique, because nothing said in it can change the result. In terms of the double diamond, which pictures design as diverging and converging twice, critiques belong in the stretch where solutions are still being spread out.
Put it on the calendar rather than calling one when needed, because the one called when needed rarely happens. Everyone agrees critique is worth doing and nobody wants to be the person who interrupts a busy week to schedule it. A fixed Thursday morning slot with a signup list for the week is the common arrangement, and an empty week simply means the slot goes unused.
How it sounds at work
"Let me take this to critique. I still have two directions open."
Going in to gather reasons for choosing, not to get a decision handed down.
"Hold the solutions for now — just tell me where you got stuck."
The facilitator pulling the room back to step 4.
"I'm taking two things from critique and leaving the rest."
A reminder that critique produces material, not instructions.
At Pagedeck, Thursday morning is the critique slot. Noa brings two versions of the document sharing permissions screen and opens by saying she can't decide between four permission levels and two. Theo points out that the four-level version doesn't fit on one line on mobile. Mia says she tried to share with the whole team and spent about thirty seconds looking for a way to do it, because the only control on screen picks people one at a time.
Noa acts on one of the two. Theo's point breaks the layout outright, so she fixes it. Mia getting stuck is one person's experience, so it goes to a usability test where five people attempt the same task before anything changes. That is everything the session settles. Which version ships gets decided at the review the following week.
What people get wrong
The most common mistake is treating critique as an inspection. Almost every occasion for showing work to other people ends in a pass or a fail, so the assumption comes naturally. But a critique has no verdict. It ends with nothing confirmed and a list of things for the maker to weigh. When people believe it's an inspection they only bring finished work, which means the moment when direction could still change has already gone by.
The other mistake is assuming harsher is better. The word critique suggests that sharpness is the point. What actually makes the format work is the phrasing, not the force. Describing where you got stuck already delivers information that stings, and it lets the maker listen without defending. When severity becomes the currency, people hide early drafts and bring only polished ones — and the stage where critique is worth the most disappears entirely.
Easily confused with
| Term | What it leaves behind | How it differs |
|---|---|---|
| Design review | A decision | Ship it or change it gets settled in the room, so the people who attend are the ones with authority and the ones whose work changes as a result |
Where to go next
- Design process
see where critique falls in the larger sequence
- Design review
the session that comes next, and the one most often confused with this
- Code review
engineering's version of the same idea, useful as a contrast
Last updated 2026-09-16