Design Review Meetings That Don’t Suck
A big part of being a designer is presenting your work to others. Let’s be honest, you may have the most amazing design chops anyone has ever seen, but if you’re unable to explain (i.e. sell) your work to clients/partners, all that talent is going to waste. The ability to run an effective design review is what separates the amateurs from the pros, and will ensure that your work moves to the next level.
After years of trial and error (lots of error), and honing the process with design partners & clients we arrived at a fairly simple formula for running design review meetings that keep participants focused on what matters and usually results in actionable & helpful feedback. If you’re ready to learn how to run design review meetings that don’t suck, read on…
The ability to run an effective design review is what separates the amateurs from the pros.
1. Share the agenda
Begin the meeting by setting everyone’s expectations about what will be covered. Make any introductions if necessary; then let attendees know approximately how long the meeting should take, what you’ll be sharing, and what kind of comments you’re looking for. Don’t gloss over that last part. Take control of the conversation immediately by telling meeting attendees exactly what kinds of feedback you want to receive as part of the review.
It’s also useful to designate a note-taker at this point (if possible, the presenter should focus on presenting rather than taking notes) who will capture important information throughout the meeting.
2. Restate the problem statement
I know you’re super excited to present your work, but there are some important topics to address first. Before showing any design options, it’s critical to lay the groundwork. In fact, most of the design review should be spent discussing and agreeing on that very groundwork. This process begins by discussing the reason we’re creating designs in the first place: sharing the problem that the designs are intended to solve.
Problem statements come in a variety of forms (How might we…? As a user…, etc.); the primary guideline is to avoid including the solution as part of the problem statement itself. Our team is fond of using the following syntax:
- I am…[description of user & current situation]
- Trying to…[accomplish a task]
- But…[reason task is difficult/impossible to accomplish]
- Because…[obstacle to task completion]
- Which makes me feel…[builds empathy for user]
Read through your problem statement with all attendees, and make sure that everybody agrees it’s the problem that the designs are intended to solve. This activity often sparks some interesting dialog and word-smithing. Ultimately, if stakeholders can’t settle on the problem statement, it’s best to refocus the meeting to build consensus and write a problem statement on which everyone can agree. In this case, it also means that you probably don’t want to share any design options until you’ve had an opportunity to refocus the work on solving the newly agreed upon problem.
What’s that you say… You don’t have a problem statement? Well, that’s another problem in and of itself. The goal of your designs should be to act as a potential solution to a stated problem. If you and your team haven’t already articulated a problem statement, do that first. Here’s a deeper dive into writing effective problem statements.
3. Business alignment
Once everyone has agreed on the problem statement, it’s time to make sure that meeting attendees are aligned about what the business is trying to achieve.
An overarching organizational mission as well as any known business objectives, strategies, and success measures that are relevant to the design work should be shared at this point. We usually organize this information on a single slide in a table that looks something like this:
Sharing this information presents another opportunity for discussion ensuring that all parties are on the same page about what the business hopes to achieve. It also helps ground the design work in the business value it’s aiming to provide.
4. Design principles & definitions
We’re almost ready to start sharing designs, but — before you do — now is a good opportunity to review any design themes or principles that are influencing the work. For example, some of the principles guiding the work my team has been doing recently include: Approachable, Motivational, Considerate of peoples’ time. When you begin presenting designs make sure to reference how you believe they’re embodying the principles, and look for feedback on whether people agree.
This is also a great time to define any terms or acronyms that may be ambiguous to make sure everyone in the room is speaking the same language.
5. It’s showtime!
Now that you’ve established some important context and built consensus, you’re finally ready to walk through the designs. Remind everyone in the meeting that you’re looking for feedback as it relates to how the designs may act as a solution to the problem, meet the business objectives, and align with the design principles.
We’ve found the most efficient way to present product/UI designs is to walk through the user flows screen-by-screen via a simple prototype (InVision is a great tool for this), and tell the story about how the user may interact with the designs in order to alleviate their problem while accomplishing stated business goals.
6. Wrap up & next steps
After walking through the designs you should have received some valuable perspectives and feedback that you may want to apply to future iterations of your work. Don’t forget to thank everyone for their time and the useful comments that were shared.
Before adjourning ask the note-taker to review relevant feedback and next steps (including people responsible for any action items and due dates) that the group can agree on before the meeting ends. That information can also be sent out in an email shortly following the meeting.
So there you have it. As I said, this is a fairly tried & true process that we’ve used to successfully present designs, but we’re always open to tweaking & refining it as we go. I’d love to hear your feedback about what works or hasn’t worked for your team while reviewing design work in the comments.
