“Empathy is a big buzzword in UX right now. There are books and blog posts espousing the idea that if designers can develop true empathy for users, then they’ll build better applications. That’s true, but what about stakeholders? Designers need to empathize with product owners, business analysts, and even executives too, if they hope to get the support they need for their projects to succeed.” -Tom Greever, Stakeholders are People Too
In Tom Greever’s UX Booth article and related book Articulating Design Decisions, he talks about the needs of stakeholders, and how important it is that designers gain their support. The rationale is that designers require stakeholder’s financial backing, as well as their recognition of the value of the end product. Without that support, a project will easily lose funding or never make it beyond the prototyping stage.
It’s easy to say that designers require stakeholder support. But there’s a step beyond this, which is to say that stakeholders are end-users as well. Sometimes they will be responsible for updating the site or application after launch. Other times they are responsible for marketing the project after launch. Regardless, there is always something the stakeholder wants from the final product, and beyond merely acting as a diplomat, a UX practitioner can actually help the stakeholder achieve his or her goal as part of the project.
Let’s look at examples of stakeholders as end-users, and explore how the stakeholder/designer relationship can result in mutual respect and partnership.
What Stakeholders Want and Customers Need
In a recent site redesign for a hospital, my team’s interviews with patients revealed a problem. Patients felt there were too many competing resources available across the web, and didn’t know what was reputable. They told us they never looked at the hospital’s blog or resources, because there was so much available on sites like WebMD, but what they did want was for the hospital to tell them which sites to trust. Yet the stakeholders on the project were clear: they had a great team of writers, and they loved having a blog. They wanted to create more web pages, more articles, more social media, and more original, proprietary resources.
It’s every designer’s worst nightmare. While we hear over and over again that we are not our users, stakeholders do not always agree with or understand that. And so our solutions attempt to fit into a perfect Venn diagram of stakeholders’ requests and customers’ (or patients’ or other end users’) needs.
The center of our Venn diagram is the ideal—even better than creating a solution that is perfect for end-users at the expense of stakeholders. The reason is that whenever possible, we as UX practitioners are looking for solutions that do not exist in a vacuum. User needs are one major component of creating project requirements, but they’re not the only component. Budget, timeline, and stakeholder requests are also valid constraints that feed into the requirements.
Stakeholder requests can become constraints when they don’t align with user needs. But not all stakeholder requests are equal. There are three key reasons stakeholders may ask for something different from what users want.
- It’s a power play. This goes back to Tom Greever’s article on empathy. Some stakeholders need to feel heard, and for them Tom recommends befriending the stakeholder to win them over. That said, the this may set up a relationship where the designer actually feels uncomfortable or disrespected by the stakeholder, which leads to other problems, some of which we’ll attempt to solve later in this article.
- The stakeholder doesn’t know the user. Sometimes stakeholders honestly believe their end-users want to watch 20 minute videos about why their company is amazing. For these stakeholders, the best case scenario is to share research results with them. Don’t tell them, but show them what customers are saying, and learn about customer needs together. The benefit to working with someone who cares about the end-user is that they want to learn more about them.
- The stakeholder has goals outside of user-centered design. This is perhaps the trickiest of the three. Some stakeholders have goals such as cutting costs, using a specific department, or proving that their idea can be successful. This is a difficult situation for a designer, because it is not a parallel goal to “creating a good experience to the user.” In this case, the stakeholder’s goal is actually a constraint for the project—something the design team needs to be aware of, and work with or work around as needed.
When it comes to stakeholder goals in particular, some stakeholders have different goals because they are users too. How do we handle that?
When clients are users
The most frequent example of clients-as-users involves a content management system (CMS). When an organization has a CMS, someone needs to author the content, and publish it using the system. The process of creating and managing content is what content strategist and author Rick Yagodich calls The Author Experience.
From his book by the same name:
Author experience (AX) focuses on the value of managing the communication process effectively and efficiently. It deals with this process from the point of view of those who create and manage content… While author experience largely means user experience within a content management experience, it is concerned with issues—creating and managing the communicated message—that often suffer from a myopic focus on end-user experience.
Rick Yagodich
What Rick is calling out here is that our focus on the end-user can sometimes blind us to the needs of authors, or site admins, who will need to be able to work within the system if we want the end-user experience to be a positive one. It is our responsibility to create positive experiences for both customers (traditional end-users) and stakeholders. We have two users to understand, two audiences, and two very different user flows or user journeys to explore.
In this case, the stakeholder’s goals will very likely differ from the user’s goals. It is our job as UX practitioners to champion both. This is a situation where communication is the key to a happy relationship, and a designer who clearly separates the two types of users will likely be able to get stakeholders on board. They will see their needs accounted for, and conversely, by accounting for stakeholder needs, the designer is setting the project up for longterm success.
When (and how) to push back
Unfortunately, designers also frequently encounter stakeholders who are making power plays. Perhaps the stakeholder honestly doesn’t understand the value of human-centered design, or perhaps there are internal politics at play. This is a complicated situation, and requires a level of empathy and understanding, as well as the ability to be assertive without coming across as aggressive.
As UX designers, we have a responsibility to the end-user. We are their champions, their voices in the design process. But when a stakeholder is making broad statements about what the team “needs to do,” or is announcing decisions counter to the best possible experience, it’s not useful to confront him or her head to head.
Instead, try some of these suggestions:
- Fall back on research. There’s no reason to get into an argument when we have quotes from actual users, and patterns identified from interviews or surveys that we can use as evidence. Whenever possible, let the research be blamed for design decisions that go against the stakeholder’s requests.
- Be a diplomat. Ideally stakeholders will respect design opinions, and ask questions rather than make statements about what the design team should do. But when things are not going ideally, we can only control our own actions. We can be diplomats, speak gently, make suggestions, and ultimately (if all goes South) decide not to work with this person in the future.
- Stand up for design choices. On the other hand, if diplomacy means significantly compromising the experience, try another tactic. Instead of focusing on “you (the stakeholder) should listen to me (the designer),” stand up for the design choice itself, and connect it to evidence-based best practices. Give stakeholders a reason to trust your decisions. In my personal experience, a difficult stakeholder can become a staunch supporter, given a little time and evidence.
- Be respectful, and ask for respect. Ultimately, some stakeholders are used to being the boss and having people afraid of him or her. But that’s not the relationship most UX practitioners want. We want to be respected for our skill, knowledge, and hard work. By showing respect but being clear and assertive, we set an example of the way we want to be treated.
- Articulating Design Decisions, by Tom Greever, has tips and advice for designers looking to become better communicators. He focuses on how designers can show empathy for their stakeholders in order to gain organizational support.
- The Author Experience, by Rick Yagodich, shows the most frequent stakeholder-as-user situation and describes how to design an author experience that complements the end-user experience.
- Dealing with UX Disagreements, by Ward Andrews, shares design thinking activities and other skills for aligning team thinking and reducing friction.
- Expand Your Influence: 6 Communication Techniques Designers Can Use to Earn Trust, by Michael Hawley suggests concrete methods for designers to “gain a high degree of influence over their organization’s overall strategy and direction.”
- Turning Stubborn Stakeholders Into UX Allies in 3 Easy Steps, by Sarah Doody, is exactly what it sounds like. Three recommendations for working with difficult stakeholders, and getting them onboard with a project plan.
Building symbiotic relationships
The best stakeholder relationships allow both parties to be heard. They are respectful, project-focused, and allow for discussion and questioning. Empathy is a start, but we can do better. We can listen to stakeholders, account for their constraints, recognize when they are end-users, and still maintain our dignity as designers.
To learn more about stakeholder relationships, check out these books and articles: