How to run a design review that ends in a decision

'Review the onboarding designs' invites every possible comment. 'Choose between a one-step and a two-step setup flow for the pilot' creates a decision. Define the audience, the release boundary, and the constraints that are already fixed. Put wider questions in a separate list so they remain visible without consuming the review.

Send the brief and options before the meeting. Include the user evidence and technical constraints behind them. If a reviewer is learning the whole problem for the first time in the call, use the session to build context and schedule the decision for when the required input is available.

• User outcome: what should the intended user be able to do?
• Usability: what evidence supports the proposed flow, and what still needs testing?
• Accessibility: what requirements must the implementation meet?
• Delivery: what scope can the team build and support for this release?
• Risk: what failure or confusion would make the choice unacceptable?

These are a starting point, not a scoring formula. Pick the few criteria relevant to the choice and state which ones are mandatory. A visual preference should not silently overrule an agreed user requirement. Equally, a delivery constraint should be stated as evidence rather than used as a vague veto.

This is a suggested agenda for a bounded review, not a guarantee that every design decision fits in 25 minutes. If essential evidence is missing, end with the question open and an owned plan to obtain it. Do not use a time box to force approval.

Ask reviewers to describe the concern and the criterion it affects. 'The second step may hide the error state from keyboard users' is actionable. 'I prefer the other version' needs a reason before it can affect the decision. Label comments as blocking concerns, testable risks, or optional suggestions.

For an illustrative onboarding review, the team might accept the two-step flow for an internal pilot, conditional on a keyboard-navigation check. Product owns the pilot boundary, design owns the error-state revision, and engineering owns verifying the interaction. The decision should name the condition; the tasks should name what evidence satisfies it.

Choice: Two-step onboarding for the internal pilot
Reason: Separates account creation from workspace setup
Condition: Keyboard navigation and errors verified
Deferred: Wider rollout pending pilot feedback
Confirmation: Required design, product, and engineering owners
Actions: Error-state revision; interaction check; pilot report
Review trigger: Pilot evidence challenges the chosen flow

Link the confirmed outcome from the design brief and implementation tasks. In the next review, start by asking what evidence changed. If a constraint or user finding is new, revisit the choice deliberately. If nothing changed, refer to the rationale instead of restarting the debate from personal memory.

Align Rooms can support the review on a shared board: the designs and the brief sit on it, and the open concerns, the decision, and the owners are pinned there as you talk. Pages keeps the brief near the decision, and Plans keeps the work connected to its reason. Use the assistant to structure the review while the people responsible for the product retain authority over the choice.

Measure the process on a few real reviews: did the team leave with a confirmed choice or a clearly owned open question, and could the implementer understand it later? That is a more useful first test than counting the number of comments the meeting generated.