Design Review Meetings That Don't Suck
The ability to run an effective design review is what separates the amateurs from the pros.
A huge part of being a professional product designer is presenting your work to others. Let’s be frank—your designs might be groundbreaking, but if you can’t explain them effectively, they’re unlikely to ever see the light of day. The ability to run an effective design review is what separates the amateurs from the pros and ensures that your work gets the buy-in it deserves.
After years of trial and error (lots & lots of error), I’ve honed a basic formula for running design review meetings that keep participants focused on what matters which will result in actionable, helpful feedback. If you’re ready to run design review meetings that don’t suck, read on.
1. Set Expectations
Introduce meeting attendees & their roles if needed, outline what will be covered (an agenda should be part of the original meeting invitation), and be clear about the type of feedback you’re looking for. This is key—take control of the conversation by steering feedback toward what will actually be useful to refining the designs. It can also be helpful to clarify any industry jargon or acronyms to ensure everyone is speaking the same language.
If possible, designate a note-taker so the presenter can focus on presenting rather than capturing feedback.
2. Reframe the Problem Statement
Before showing any design work, lay the groundwork by restating the problem. Most of the time spent during the design review should focus on ensuring alignment on the foundational problem and how the design is intended to address it.
The following is my go-to problem statement syntax:
As I (persona) …
When (trigger) …
I want to (action) …
So I can (outcome) …
But (blocker/problem)…
Read through the problem statement with all attendees and confirm alignment. If there’s any disagreement, pause the review and focus on clarifying and building consensus on the problem. This may require reworking the designs and postponing the review depending on the outcome of the problem statement discussion. If the team can’t agree on the problem, it’s too soon to review solutions.
3. Align on Business Goals
Once the problem statement is agreed upon, ensure everyone understands and is on board with the business objectives that the designs aim to support. Share relevant vision statements, success metrics, and strategic goals in a simple, digestible format.
Example:
Business Objective: Increase user retention by 10% in six months
Strategy: Improve the onboarding experience
Success Metric: Reduce time-to-value for new users by 30%
When everyone is aligned on these goals, it helps frame design discussions around potential impact rather than personal preference.
4. Establish Design Principles & Definitions
Ready to share those designs? Not quite… Before diving into designs, remind the team of any design principles guiding the work. For example:
Approachable – Feels familiar and easy to use
Efficient – Helps users complete tasks quickly
Trustworthy – Communicates transparency and reliability
Reference these principles when presenting your work, and ask for feedback based on them, e.g., “do you think the interface is clear and breeds trust?” Basing feedback on principles keeps the discussion focused and reduces subjective design debates.
5. Present the Designs
Now you’re finally ready to walk through your work. Remind attendees that feedback should stick to how well the designs solve the agreed-upon problem, align with business goals, and adhere to design principles.
The most effective way to present your designs is via storytelling. Walk through a user flow, screen by screen, using an interactive prototype. Tell the story of how a user would interact with the design to achieve their goal. If the story is unclear to you or the attendees of the design review, it’s probably going to be unclear to your target audience.
6. Wrap Up & Define Next Steps
Before ending the meeting, summarize key feedback & takeaways. Have the note-taker review relevant feedback to make sure everything was captured, identify action items, and assign owners with due dates. Confirm that everyone agrees on the next steps before wrapping up.
Send a follow up email summarizing:
Decisions made
Action items & owners
Next review or check-in date
Final Thoughts
This process has helped me and my teams run efficient, productive design reviews that lead to better outcomes. But every team is different. Incorporate these concepts into your process to determine what works best for your team.
