How to Present a Design Review
Arguably the most difficult skill you’ll learn in your design career is how to communicate that you did what you set out to do in a way that gets people to support and continue the work you did.
Presenting design successfully is about knowing what you want out of the meeting and structuring it to meet those needs. There’s a cliche of design reviews as interpersonally fraught spaces where stakeholders alternate between going on tangents and ripping your work apart. It doesn’t have to be that way.
Ideally, you’re using what you’ve designed as a way of understanding the needs of the people you’re meeting with more thoroughly. You explain what you hoped to achieve with the design, they explain what they need the design to do, and the review is about how to square those two in a way that satisfies user goals. (This is a great ideal whether you’re meeting internally or with an external stakeholders team: you’re never gonna go wrong getting better at design reviews.)
Establish a shared understanding
At the top of the meeting, confirm the duration and goals of the meeting. This will help people understand when to go into detail and when to organize a breakout session, and will help keep feedback appropriate to where you are in the design process. Bonus points for explaining the goals of the meeting from the user and business perspective.
I like keeping people up to date by having design reviews frequently (weekly is best, every other week is okay). Some designers share out their work the day before so everyone who will be present in the meeting will have time to prepare.
Socializing your work is scary, but important. When people are surprised by changes, they may assert control in ways that don’t necessarily further the goal of the project. It’s important that no one feel caught off guard by the design work you’re presenting.
Help, there’s a stranger in my design review!
Sometimes, meeting invitations spiral out of control and you’ll end up with folks from outside the project reviewing your work. It’s important to understand why they’re there and what’s at stake for them before you internalize their feedback. It’s also appropriate to review the project history and goals with them before design review so no one is coming in blind and delivering feedback on the spot.
When I talked to the other designers at Carbon Five about this, they mentioned that project kickoff is a great time to set expectations around attendance and etiquette and get attendance commitments from the folks who will need to approve design. Knowing that some people will only be able to make monthly design reviews, for example, will help you set the agenda and prepare your drop-in stakeholders beforehand.
If you’ve got people in the meeting who care about the outcome of the project but have less direct involvement, be ready to explain the work in terms of the effect it will have on them. “We want to increase our sign-up completion rate by 10% with the next release, so we’re addressing user feedback that the sign up process takes too long” is going to be a more compelling design rationale than “everyone else is doing keyboard-only form input.”
What kind of feedback do you want?
Feedback that comes too early and isn’t correctly managed can hang over your design like an albatross… if you let it. Without clearly stated objectives, your audience won’t know what kind of feedback is going to help you and may say whatever random things pop into their head. Set the scene at the top of the meeting (e.g., we’re going to use this wireframe to go over the order and verbiage for the navigation in the desktop and mobile states) to get everyone talking about the same thing.
Your audience is as scared of you as you are of them
Design is a nebulous, squirrely thing with tendrils in a lot of different disciplines, and you need a lot of input from everyone — subject matter experts, developers responsible for implementation, and users — to make a design successful.
Still, a lot of the people who will be directly affected by the design don’t know how to evaluate it, and part of your job is to educate them. Some designers like to go into meetings like Don Draper and sell an audience on a vision. I like going in more like Bill Nye, explaining the design terminology and rationale behind my work until everyone understands the core principles a little better. Anything that helps your audience feel qualified to offer their expertise within the scope of the review is worth the effort.
It doesn’t matter if your audience likes it
The tastes and expectations of the stakeholders are absolutely going to affect your design whether you solicit them or not, but design reviews aren’t about catering to the taste of the folks in the room. We’re trying to design a successful product that meets business and user needs. Why ask “Is it good?” when the question could be “Do we think this solution will positively affect the people we’re trying to reach?”
What if they go outside the desired sphere of feedback anyway?
If a stakeholder really wants to give feedback outside of the goals you set out for the meeting, you have two options: take the feedback or push back.
If you feel like their feedback was on point, write it down and promise to look into it further. Then research it and offer them a thoughtful response in the next design presentation.
If you disagree, and you have established a good level of trust, you can gently remind your audience of the scope of the meeting and refocus the conversation to keep it from going off on a feedback tangent.
Vision, then details
When you’re done presenting, try asking someone in the room to present it back to you.
For instance, ask someone in the room to articulate the user’s goals in going through a sign-up flow. If no one can explain why a user is engaging with this piece of the product, it might not be the time to talk about whether the colors are right.
Focus on one thing if you want the group to focus on one thing
Making too many changes at once in a design can split the attention of a room and derail a meeting. If you want feedback about information hierarchy, focus on making changes to your information hierarchy. For example, if you add fields to a form and change the font at the same time, your audience is more likely to fixate on the choice of font and won’t offer feedback on whether those additional fields are necessary.
Sometimes you need to present changes to multiple dimensions for feedback in a single meeting. If you can take the time, split each dimension into separate artifacts to keep everyone focused on a single dimension. This is where things like style tiles and wireframes come in handy — they keep things separate until it’s time to see them together.
Presenting options
Sometimes the best way to get feedback on design is to show a few different design directions. Seeing different solutions to the same problem can help folks in the meeting focus on a unified design direction rather than blue-sky feature pitching. It can also demonstrate to skeptical stakeholders that you’ve considered different options and made thoughtful choices.
I’ve worked with designers who put a lot of work into ordering the options they present to make the case for the design direction they think is most interesting. My preference is to put my energy into detailing the pros and cons of the different design directions.
Keep an open mind about the strengths and weaknesses of your design options when you present – and take the time to acknowledge the broader context of the work. Factors like brand legacy, implementation cost, and looking different from the competition matter as much as the formal qualities of design. One option might address an edge case user very effectively and one might take less time to build. One might talk very specifically to an existing customer, one might be geared at broader acquisition at the expense of alienating existing customers. It’s up to the product owner to determine which aligns with their strategy.
If none of the work you present aligns well to the broader strategy, or there are unknowns in determining which option is going to work out the best, set aside some time after the meeting to test the versions with users, or agree to iterate on the design with a little more data.
Developers in Design Review
If you depend on other people to bring the final design into the world, it matters what they have to say. I worked briefly in signage and packaging, and relied on the pre-press team to tell me whether a design would look good in the real world or if it was likely to encounter problems in shipping or production. Design is only as good as the final product.
Nowadays, I work with developers and invite them to design reviews for their perspective. Developers can articulate hidden pitfalls and edge cases you might not have considered. If building a design is going to create changes to the underlying data model or add a much higher implementation cost, the product owner will want to factor that into their decision. If you’re worried about developer feedback derailing the meeting, make sure to check in with developers beforehand and present their feedback as part of your presentation.
The Frankenstein Option
Sometimes you’ll make inferences about how everything is going to fit together in presenting design options and discover that the team likes a little bit of each. Sometimes that’s okay. Sometimes it’s really, really irritating.
The good news is that you’ve got the attention of everyone in the design review, and they’re invested in the outcome. If you’ve got a team that’s prone to combining elements like this and you’re at a phase in the project where it feels appropriate, set aside some time during review to recombine the elements as a group. Talk about whether the new composite version feels complete. You can even hand your design reviewers scissors so they can cut and paste elements that are working.
If Frankenstein versions aren’t the right solution, there are ways to prepare before the meeting starts. Get another designer to confirm that you’re presenting strong, distinct options rather than unclear iterations on the same basic style. Take the time to break your work down into separate artifacts and confirm them separately before showing them in combination.
Either way, it’s important to get the folks in design review to articulate why each sub-option works for them and why they work well together. That additional piece of context is the difference between a clear and actionable design direction and a design by committee. Write their notes down and reference them in the next design review, where you present the final composite design.
Questions and feedback
Design, as many other people have noted, might be visual but it isn’t an art. The work we’re presenting is informed by stakeholder interviews, competitive analysis, analytics, and user research. This is where you’re going to want to be able to back up the design decisions you’ve made with the data you’ve gathered.
Justifying your decision-making is different from getting defensive. Ideally, everything you’ve done is mapped to a best practice, a piece of user feedback, or a business priority. You’re offering additional context for the design rather than telling the person who asked why they’re wrong to criticize you. If you don’t know or remember why a decision was included in the design you’re presenting, write it down and address the decision in another design review.
End it
Watch the time on the meeting and make sure to save 5-10 minutes at the end for a recap. This is where you read back the notes you’ve taken based on the questions and feedback of the people assembled to make sure you heard them correctly.
In the end you should have a list of actionable feedback and feel prepared to start on a new iteration of the design. Ideally, you know who said what about what, and you can start the next meeting by talking about how you addressed each valid concern.
Design reviews are one of the best — and highest stakes — tools a designer has for helping the extended team feel represented in the product. These reviews can build trust and make everyone on the team feel like their contributions matter. You’re offering the broader organization the opportunity to champion your team’s hard work and make the final project as successful as it can be.
Finally, set a time and a rough topic for your next design presentation — then put your headphones back on — you’re done until next time!
Illustrations by the author.
