Successful design reviews have less to do with the specific design decisions you and your team are presenting, and more to do with aligned expectations between what colleagues think they will see and what they actually see in that session.
I’ve seen a lot of designers fail when presenting their work to other people. Personally, I’ve had a lot of failures myself. In most cases, I have come to the realization that an unsuccessful or unfulfilling meeting has less to do with the quality of the designs that were presented, and more to do with miscommunications that happened between the designer and their audience.
When you walk into a room to share your design work with your peers, stakeholders and clients, you need to remember there’s an inevitable gap between what they are expecting to see and the actual work you are showing in that session.
It’s all about putting yourself in their shoes:
- You are coming hot, they are coming cold. You have been working on that design challenge for several days, but they haven’t necessarily seen or heard anything since the last time you talked.
- Your designs are just 10% of the projects and issues they are dealing with that week. Sometimes it’s hard for people to shift their mindset and focus on the one specific challenge you will discuss in that session.
- Unless you explicitly tell them, they don’t know the type of feedback you are expecting to receive at that point in time.
- Business stakeholders have to understand how the design decisions you and your team have made will impact the backend of their operations.
Take a few minutes at the beginning of the meeting to set up the right expectations before you jump into showing designs. In certain contexts and for certain audiences, putting together a few setup slides (or even artboards in your Sketch file) can be extremely effective to ensure everyone is on the same page in regards to what they will be seeing in that session.
The more thoughtful and inclusive these setups are, higher the chances the review itself will go well once everyone starts looking at the designs you have produced.
Here is an outline of what I usually try to cover in those initial minutes:
#1 Play back what you have heard
It’s been a while since the last time that same group gathered in a room to chat about that task/project you have been working on. Since the last time you met, lots have happened — decisions were made, business priorities have changed, departments have been reorganized, other features have been launched.
Look around and see who is in the room: when was the last time each person heard about this project/feature you’re sharing today, and what did they hear?
Then use the first couple minutes to recap:
- The goal of this project/feature
- The requirements you heard when you were briefed
- Any major shifts in direction that might have happened along the way
#2 Explain what you have done, and why
Give your team a peek into what you have been working on. There might have been a lot of research (user research, benchmark, interviews) you have done that will not necessarily come across if you jump straight into showing mockups or prototypes. This is important for them to understand whether you have talked to the right people, who has been involved in the decisions, and how much rigor you have put into the process.
Resist the temptation of spending too much time on this, though. No one wants to see a diagram of your design process, or a timeline of the activities you’ve done; all they need is minimum reassurance that you have made well-informed design decisions.
#3 Show how this is different
Why are you showing these designs in the first place? How do you think this version is better than the old one (in case of a redesign), or how do you think this new feature will help the company achieve their business goals faster and meet their user needs in a more relevant way?
#4 Tell them why you’re personally excited about it
Show how much skin you have in the game. What are your personal goals, what are your department’s goals, and why are you excited to share the work you’ll be showing in that session? This is a great opportunity to connect to your colleagues at a more personal level, and show them you are personally invested in seeing those designs succeed.
#5 Set up what they will see
This is obvious, still a lot of people miss the mark. Giving people a quick list of the screens and flows you’ll be reviewing can mitigate anxiety and get them in the right mindset for the remainder of the session. Knowing that you’ll cover certain features later in the presentation will prevent people from interrupting your presentation to ask questions that they know will be answered in a few minutes.
#6 Explain the type of feedback that will be the most helpful
What are you expecting to get out of this session? Where are you in the overall project timeline, and what type of feedback will me the most helpful? If this is the first round of conceptual design, people will know to give you ideas rather than specific feedback; if this is the last review before developers start their sprint, people will know they should be giving you detailed feedback.
#7 Now, and only now, show the work
This article is part of Journey: lessons from the amazing journey of being a designer.
Top comments (1)
Especially with the redesign, I would put the old application and the new design in front of the stakeholders and other designers to highlight some of the major changes I made. That allows them to have a visual guide they can use to follow my presentation.