Design Review
Practice
A session where the people affected by a design look at it together before it goes to engineering and leave with a decision about it.
Why it exists
There was a time when a finished mockup meant sending a file to engineering and moving on. The problem is that when the file arrives, exactly one person has looked at that screen: the designer who made it.
Pagedeck lived this. Theo built from the mockup for three days before Mia saw the screen and said nobody had agreed to add a confirmation step before checkout. Noa had added it because support kept getting the same question; Mia pointed out that the quarter's goal was to reduce checkout drop-off, so adding a step was the wrong direction. All three were right about their own piece. Those pieces just met each other three days into the build.
Vague approval creates the same damage. Nobody can tell whether the founder saying "nice" in the hallway was an approval or a reaction, work continues on that basis, and when it gets reversed right before launch there is no record of who decided what, or when.
Under the design process, the collaboration branch holds three practices. All three put work in front of other people; what separates them is what you are trying to get back. Design review is the one you open to get a decision.
How it runs
Because a conclusion has to exist at the end, the order is built toward one. Six steps.
- Send the material out a day ahead, with one line naming what has to be decided. Something specific, like "we're deciding whether sharing permissions attach to a document or to a folder." Without that line people arrive unprepared and see the screens for the first time in the room.
- Give the background in three minutes: which problem this solves, and what is already fixed and cannot move. Skip the constraints and ten minutes disappear into options that were closed weeks ago.
- Walk the screens in flow order instead of laying them out one by one. If there's a clickable prototype, use it. What breaks between two screens rarely shows up in a still image — a step that feels obvious on its own page turns out to have no way back to the previous one.
- Take questions first, opinions second. Reverse the order and opinions built on misunderstandings pile up, and the rest of the session goes into clearing them.
- State the conclusion out loud in the room. It's one of three: this goes to engineering as is; fix these specific things and it goes without meeting again; we look at it again — and if it's the third, the date gets set now.
- Write down what was decided and what wasn't. Open items get an owner and a date. That record is what later tells design handoff which parts are settled.
A session runs 30 to 45 minutes and holds two or three items at most. Put five on the agenda and the last two get "let's just proceed" as the clock runs out, which is a deferral wearing a decision's clothes.
Who joins and when
The invitation rule is influence, not interest. Invite the people whose own work changes because of the decision, and leave everyone else to the notes.
Three seats are always there: the designer who made the mockup, the product manager who set what gets built and why, and the engineer who will build the screen. Mia checks it against the quarter's goal; Theo answers on the spot how long it takes and whether anything is technically blocked. With those three in the room, most reversals happen before the build starts rather than after.
Other seats come and go with the subject. Grace joins for pricing screens or anything that shapes the product's impression, and Sofia joins when something already promised to a customer is involved. People who aren't affected by the decision stay out. Ten people in a room produce ten opinions, three or four of which feed the decision, while the rest become a debt of explaining later why they weren't taken.
Timing is right after several options have narrowed to one, and before the build starts. While options are still being spread out, this session is premature — you end up asking for approval on something nobody has chosen yet. On the double diamond, review belongs at the closing edge of the second diamond. Large features get two: one to settle the flow, one to settle the screens. Try to settle both at once and the flow conversation and the spacing conversation tangle until neither closes.
How it sounds at work
"I'll bring it to design review this week. We only need to settle the permission scope."
Narrowing the agenda to one item in order to leave with a decision.
"It passed review conditionally. We fix the error copy and send it straight over."
Only the named parts change, and there's no second meeting.
"That wasn't decided in the review, it was just something someone said."
Drawing the line between recorded decisions and remarks made in the room.
Pagedeck holds a standing 45-minute slot on Thursday afternoon. Noa posts the mockups and the one-line question a day ahead, and Mia and Theo come in having read it. Weeks with nothing to decide, the slot is simply cancelled.
What changed after the session became routine is the number of screens reversed after the build started — it used to happen three or four times a quarter and now barely once. The number of reviews didn't go up to get there. What went up is how often Mia and Theo see a mockup before it's handed over.
What people get wrong
Many people read a review as a place where the designer gets judged. Standing in front of a group with your own work on screen and collecting comments feels exactly like that. But what gets judged here is the next action, not the person. Once it reads as evaluation, designers only bring work they can defend, and anything they're less sure about never goes up — which means the decisions that most needed other eyes skip the review and go straight to engineering.
The other common belief is that inviting more people is safer. The invite list grows to prevent anyone saying later they weren't told, and the larger it gets the slower conclusions arrive. Past about six people the room stops deciding and starts informing, and the real decision happens afterward among the two or three who stayed behind. The people who need to know and the people who need to decide are different groups, and the first group is served by the written record rather than by a seat.
Easily confused with
| Term | What you open it to get | How it differs |
|---|---|---|
| Design critique | A read on which users would get stuck where | Nothing is concluded at the end. It gathers peers doing the same craft to pull an option apart, so it belongs while options are still spreading out; review belongs after they've narrowed to one |
Where to go next
- Design process
see which slot of the full sequence this session occupies
- Design critique
compare the session that gathers similar people for a different purpose
Last updated 2026-09-16