Part 5 · 1 chapters · ~8 min
Running a Design Review
Preparing reviewers, asynchronous comments first, silent reading, a meeting agenda built from open questions, facilitation and including quiet voices, separating blocking concerns from preferences, disagree and commit, recording outcomes in ADRs, and reviewing others' designs constructively.
7
Facilitation and feedback
| as a reviewer, write… | instead of… |
|---|---|
| "Blocking: if the webhook arrives before the payout row commits, the handler 404s and the rail stops retrying after 3 attempts. Can the inbox accept unknown ids and match later?" | "This won't work." |
| "Non-blocking preference: I would name it payout_events, not hooks; fine either way." | "Rename this." |
| "Question: what happens to in-flight payouts during the flag flip?" | "Did you think about migration?" |
Label every comment as blocking, non-blocking or question, so authors know what must change. Disagree and commit: once the named decider decides, the team commits fully, and the disagreement is recorded in the ADR's consequences so it can be revisited if its prediction comes true.
A DESIGN REVIEW THAT RESOLVES THINGS
before, during and after a 45-minute meeting
swipe the figure sideways, or tap expand for full screen
1/4
async first
Share the document days ahead; most comments are resolved in writing, so the meeting only handles what needs discussion.
comments before the meetingmeeting for the rest