Most design reviews go wrong before the first slide appears. The problem isn't the design — it's the setup. Presenters walk in without a clear ask, stakeholders walk in without shared context, and thirty minutes later everyone leaves with different ideas about what just happened and what comes next.

Know your ask before you start

Every design review needs a clear, stated purpose. Are you here to get approval to move into build? To pressure-test a direction before committing more time? To gather input on a specific unresolved question? State this at the start, before you show anything. 'Today I need a go or no-go decision on this direction' produces a different conversation than 'I wanted to share where we are.' The first is a meeting. The second is a presentation.

Bring a point of view, not options

Showing three equally weighted options transfers the design decision to the room. That's not your job — it's theirs, and they didn't come to the meeting to do your job. If you've done three explorations, come with a recommendation. Show the others as context for the decision, not as genuine alternatives. 'We explored three directions. We recommend this one, for these reasons' is a designer doing their job. 'We couldn't decide' is a designer asking the room to do it for them.

Lead with the problem, not the solution

Stakeholders who haven't been in the weeds of the problem will push back on solutions before they understand why the solution exists. A thirty-second reminder of the problem — what users were experiencing, what the data showed, what the business needed — creates the frame for evaluating the design. Without it, feedback defaults to personal preference. With it, feedback is anchored to whether the design solves the problem.

Manage feedback in the room

Not all feedback is equal and not all of it belongs in the session. Learn to separate input that changes the direction from input that belongs in a follow-up. 'That's a useful flag — I'll look at that for the next iteration' keeps the session moving without dismissing the point. What you want to prevent is a sidebar on button colour when you need a decision on information architecture.

End with a decision, not a summary

The last two minutes of a design review are the most important. State what was decided, what was raised for follow-up, and what the next step is. 'We've agreed to proceed with direction B. I'll incorporate the feedback on the error states and share an updated version by Thursday' is how you leave a meeting with clarity. Anything less, and you're back to everyone having different ideas about what just happened.