A well-run design review is one of the highest-leverage events in a product team. A poorly-run one is demoralizing, produces contradictory feedback, and leaves the designer no clearer on what to do next. The difference is almost entirely process.
The Pre-Read
Effective design reviews start before the meeting. Share a Loom or written brief 24 hours before: what problem we're solving, what constraints we're operating under, where we are in the process (concept vs final), and specifically what kind of feedback is useful at this stage. Pre-reads convert cold reactions into informed responses.
Framing the Review
Open the review by restating the problem and the question you need answered. "We're trying to decide between these two approaches for the payment confirmation flow, and we specifically want to know whether the cost breakdown is clear enough for users who haven't used us before." Focused questions produce focused feedback.
Types of Feedback to Name
Distinguish between: direction feedback (big picture concerns about approach), detail feedback (specific element concerns), and preference (personal taste that may not be a problem). Naming these types makes it easier to process: direction feedback must be addressed, detail feedback should be considered, preference is optional input.
Closing With Next Actions
Every review ends with explicit next actions: who's doing what, and when. "I'll explore the alternative layout for the cost breakdown and come back Thursday" is closure. "Great discussion, I'll incorporate the feedback" is not.