The art of communicating with our stakeholders
Designers are artists, developers, and UX experts. Above all, however, I’ve learned that product designers are communicators. We leverage design as a medium to help our users accomplish their goals. Before we can communicate with our end-users, however, we must be adept at communicating with our stakeholders.
Gaining the trust of our stakeholders will make or break our design decisions, and in turn, will affect what our users will see and feel. So, to be good product designers or engineers, we must be able to articulate and defend our design decisions by removing the subjectivity from our choices.
Who are our stakeholders?
Before we can convince our stakeholders to trust us with our design choices, let us take a step back to fully understand who our stakeholders are.
Stakeholders come in many forms: managers, executives, developers/engineers, product owners, project managers, and marketing teams just to name a few. As you can see, they consist of a wide variety of roles with varying responsibilities.
Identify stakeholder values
Our time is very valuable, as is our stakeholder’s time. By identifying their responsibilities and values beforehand, we can use the time we have together more efficiently.
Let’s evaluate how they spend their efforts to determine how to use their time efficiently.
Before I step into any engineering or design meeting, I like to glance over this chart to remind myself of my audience. Professionals with more experience tend to have a natural instinct for this, but I highly suggest keeping this chart with you if you’re new to the industry like me!
Empathize with our stakeholders (by asking good questions)
The first step to effective communication is to find out your stakeholder’s ideals, goals, and priorities; because they’re going to differ from yours majority of the time. According to Tom Greever in Articulating Design Decisions, asking the following questions will not only find out what’s important to them, but will also help us when forming our responses, design pitches, and just generally getting them to agree with us.
- What’s your opinion on the project?
- How does this project affect your job?
- What is your priority for this project?
Stakeholders will say they trust you but will often overrule you. The problem isn’t with them, they have an equally vested interest in the company. We just need to include them in a way that’s helpful to our common goal of a great user experience and product.
To summarize: Put yourself in the stakeholder’s shoes and empathize with them- just like you would for a user. Just as you would conduct a user interview, conduct a “stakeholder interview” and find out their values and pain points for the project.
Remove their cognitive load
In my experience, meetings can sometimes be difficult to keep on track. If the purpose of the meeting is to gain approval on a design, remove distractions that can sway the flow of the meeting.
People tend to get distracted by details of design, so removing them altogether with these tips can keep them focused on what’s important.
- Use Lorem ipsum
- Remove color from your low fidelity prototypes
- Remove images from all fidelity prototypes
- Don’t confuse them with vocab
If you’re an engineer (although this article is mainly centered towards designers), this might look a little different. Sometimes specific code snippets are useful for proof of concepts but it really depends on the situation and your audience. When it comes to explaining my test plan, I usually avoid pointing out specific test scenarios completely and just rely on classifying what needs to be automated vs. what should be manually tested.
When listening to our stakeholders…
Be sure to let them talk. They may not be used to the design language that we speak, but the more time they have to articulate themselves, the more clear they will be about their expectations.
On that note, stakeholders also tend to naturally come up with solutions before they define the problem- especially in design. Even when those solutions might not work, we should use their suggestions to formally define the problem. Once the problem is actually identified, we can go ahead and solve it appropriately (or explain why our design does a better job of solving it than the alternatives).
Another benefit of encouraging stakeholders to speak is that it helps us find out the factors (impressions, conversions, signups, etc.) that they prioritize. Knowing specific metrics that might be tracked in the future can help you back up your designs when it comes time to implementing them.
When it comes time to respond to your stakeholders, you’ll be prepared to make a compelling argument for your ideas.
Stakeholders will agree with us if we show them…
How our design will help the business. Bring in the KPIs and metrics that your stakeholder cares about. Addressing those metrics, and how your designs will meet them, will show that you’ve been careful and thoughtful in your process. Also, if your ideas facilitate a primary use case of the product, or establishes branding, it automatically provides business value. So it’s useful to double-check the product’s documentation and use cases.
How it makes it easier for our users. As our user’s biggest advocates, we can represent them in our meetings by presenting user research. Usability testing, user research, and A/B tests are perhaps our most powerful weapons. Showing them recorded clips and quoting users in a PowerPoint format is highly effective. We can clearly and directly explain the inferences we made from the feedback we received, and how we tweaked our designs accordingly. Another benefit of showing footage and quotes is that it allows our stakeholders to empathize with their users, and trust you to make the best decisions for them.
Leveraging design patterns commonly found in the industry is also important. It not only proves that your solution is feasible to implement, but that it’s also highly effective and commonly used already. If your app follows a consistency, the user will know what to expect.
How it’s better than the alternatives. It’s always useful to prototype the alternatives as well as your own solution. When the stakeholders are able to evaluate that the opportunity cost of choosing your solution is low enough, they’ll go with your design. Allowing them to visualize the other options will give them peace of mind and minimize potential regret. They’ll also trust you more to make good decisions in the future because they know you also have their best interest in mind.
The limitations that may block us. This one is a bit obvious. Any limitations that can block us from accomplishing our goal should obviously be brought forth immediately. The quicker our stakeholders know, the better. Possible limitations include limited resources, limited technology, or non-compliance with standards.
The long term goal of building trust with stakeholders is to come to a place where their default response is to assume that our choices are right from the beginning. All in all, communication with our stakeholders will be defined by how we empathize with them, how articulate we are, and how much they trust us.
