Prepare a Design Review: From a One-Page Brief to a Decision
A review rarely goes badly because people argued too little. It goes badly because the goal, the boundaries, and the real points of disagreement were never put on the table. This workflow moves that work before the meeting.
How to do it
Step 1: Write a one-page brief before you draw anything
Use “A Brief for Your Designer” to write down the target user, the single problem this version solves, what it deliberately does not do, the success criteria, and the constraints. Without this page, the review turns into a vote on taste. Read it back and ask: could someone else make a similar call from this?
Step 2: Turn the brief into a design spec people can review
Use “Turn a Requirement into a Design Spec” to expand the page into information hierarchy, key states, edge cases, and acceptance criteria. Ask it to mark whatever is still unclear. Those marks are the agenda; do not cover them with polished language.
Step 3: Review your own work first and fix what is obvious
Feed the draft or a screenshot to “UI Design Review” and ask for problems ranked by severity across hierarchy, usability, and state coverage. Fix what you can fix yourself. Do not bring obvious defects into the room; bring only the points where reasonable people would disagree.
Step 4: Red-team the proposal and prepare for three hard questions
Use “Red-Team My Judgment” and have it play the harshest reviewer, attacking only the weakest assumptions. Keep the three sharpest questions, each with a one-sentence answer and one piece of evidence: a user quote, a number, or a competitor's approach. If you cannot answer in the room, log it as an open item instead of improvising.
Step 5: Hand off the approved outcome as a spec
Use “Spacing and Hierarchy Spec for Developers” to turn what was agreed into a handoff note covering hierarchy, spacing, states, and interactions. Mark anything unresolved as open and name who decides it. Otherwise engineering implements its own reading and the next review starts over.
Prompts used
FAQ
What should I prepare before a design review?
A one-page brief with the goal and the boundaries, a draft people can point at, and the three questions most likely to trip you up. The draft does not need to be perfect, but every decision should have a reason you can say out loud.
What if my designer and I disagree in the review?
Bring the disagreement back to the success criteria and the user scenario, not to taste. Use “Red-Team My Judgment” to lay out both sets of assumptions, decide only what can be verified, and agree on how the rest will be tested.
I have no designer and only my own prototype. Does this still work?
Yes. Replace “A Brief for Your Designer” with constraints you write for yourself, and feed the screenshot or a written description straight into “UI Design Review”. Focus on state coverage and whether the hierarchy holds up.