Having Trouble with Stakeholders? Try Treating Them as Users

Stakeholders can get a bad reputation. Sometimes they don't value user research, can't find time for it, or ignore the findings in favor of assumptions or opinions. As a result, at times I have felt frustrated and helpless when working with stakeholders.

I didn't know how to include them in my process or get them to care about my research. I also didn't realize stakeholders could hold a wealth of helpful and actionable information.

It took me years before a shift in my mindset finally occurred—it was like a key unlocking a hidden mystery that was in front of my face the whole time. However, it was easy not to see it and is easy to forget.

The advice might sound simple, but I needed to hear it (and repeat it to myself): stakeholders are our users.

Stakeholders as users

Viewing my stakeholders as users changed many things for me, as it forced me to adjust the way I worked and interacted with them.

We constantly tell our teams to focus on our users. Whenever they aren't sure about something, we tell them to ask users. Whenever they want to make decisions, we beg them to keep users in mind. We ask them to empathize with users.

Yet, do we do this with stakeholders?

At various times in my career, I was upset and frustrated with my stakeholders. They wouldn't engage in research, or they didn't care about learning the correct way to engage with user research.

I would try to get them to stop coming to me with a method in mind and encourage them to come to me with questions. But repeatedly, they wanted to "do user testing to validate designs." When, in reality, they needed to test a concept.

I would spend hours on reports or deliverables, and no one seemed to care. At one point, when I was working with a low budget, I created my own repository from scratch.

I got a few developer friends to help, making it perfect. My stakeholders could not ignore research now because I had set them up for success. They didn't use the repository.

I spun in circles until I realized what I was doing. I created reports, personas, repositories, and even research projects, but these outcomes were mine. I made them based on the rules and best practices I had learned over the years.

Years of Googling how to create a journey map, reading articles and books, and taking courses had culminated in me learning specific techniques. But, in a given moment, I couldn't tell you why certain information was the best to put in a persona, just that it was.

And that was the key for me. I'd committed the acts we begged teams not to do. I had ignored my users. I didn't think about their needs, goals, pain points, or motivations. Instead, I thought about what I was taught to do. And I made so many assumptions about what I learned was the right way of doing things.

But our stakeholders are our users, and it is crucial to think about them in this way. If we don't, we risk missing the mark on our deliverables and potentially our entire process. It’s the equivalent of asking a designer to create something without any user feedback.

And that has to change.

How to shift your mindset

It took me some time to get into this mindset and recalibrate how I worked with my colleagues, but it was one of the most significant changes I made. Here are some strategies I tried that made a big difference in working with stakeholders:

Empathize with stakeholders

It’s important to practice what we tell others. We need to empathize with our stakeholders because they are ultimately the users of our information. They use our products, such as reports, repositories, and deliverables. We ask them to be a part of our process.

If we don't understand our stakeholders, how do we create an experience for them that aligns with their needs and goals and that alleviates their pain points?

We need to get our research hats on and step into our role as user researchers, looking internally at our teams, rather than externally at users. I use the same tactics with stakeholders as in my one-on-one interview sessions.

When I set up 60-minute one-on-one sessions with each stakeholder, I explain that I want to understand more about their role, goals, and previous experience with user research.

In those sessions, I cover two main topics:

1. Their goals, needs, and pain points within their role
2. Their previous experience with user research

Goals, needs, and pain point questions

Within the first section, I dive into the following questions:

• What are your main goals day-to-day? For this quarter? Beyond?
• What would you like to achieve yourself? With your team?
• What are some metrics/OKRs that you would like to improve? Why?
• What would the ideal outcome be by the end of this quarter? The end of the year?
• What areas are you struggling with when it comes to achieving these goals?
• What are some of your ideas to achieve these goals/OKRs/metrics?
• What are generally some areas in the process that you struggle with? How would you improve this?

Previous experience with UX research questions

To understand more about their previous (and future) experience with user research, I ask:

• If I asked you to define user research for me, how would you explain it?
• Have you ever worked with a user researcher before? If yes, tell me about the experience?
• How do you feel about user research?
• Tell me what happened the last time you did user research.
• Tell me about a time when research went poorly. What happened? How would you improve it?
• What are the most significant barriers you feel to conducting or including user research?
• How could we improve our relationship?
• How could you imagine user research helping you with (the goals, needs, and pain points mentioned above)?

Do your best to have these conversations as openly and objectively as possible. These sessions are not the time to defend or push research. Instead, they are an opportunity to listen and learn so that you can better help your team.

Use their goals to inform your work

Once you better understand stakeholders’ goals, this can help you prioritize research projects, understand research questions, and create helpful deliverables for the team.

For instance, one of my teams focused on retention. I first took the time to understand the team's goals and OKRs to know important metrics. I also understood how these metrics aligned with the broader organizational goals. With this in mind, I understood which projects to prioritize and the most impactful work I could do for the team.

When colleagues came to me with research questions, I knew the context behind them and what they were trying to achieve, making it easier for me to form projects to help them achieve those goals. After some time, I was able to bring up strategic research projects that had a very positive influence on their goals.

Use stakeholder interviews

As I mentioned, stakeholders can be a gold mine for information. Pulling them into our process early and often is critical, and stakeholder interviews are the perfect way to do this.

During a stakeholder interview, I take the time to understand any information my colleague has on the upcoming project, both from a business and user perspective. I ask questions like:

Business/tech-based questions:

• How can this project impact the organization?
• How did you come up with this project/idea?
• What does the competition look like?
• What is the larger vision (if any)?
• What is your definition of success for this project?
• Are there any technical limitations?

User-based questions:

• Who are the users? How do they represent our audience?
• What is the problem they are facing?
• Why is this problem important?
• What is the risk/impact of solving this problem?
• (If necessary) What are some ideas you have to solve this problem? Why these ideas?

Ask them what they need from the deliverable/outcome

Ask your stakeholders what they need before creating (and if you're anything like me, perfecting) a deliverable. Similar to understanding their overarching goals and needs, this is a step you can use on a project basis.

Outcomes from research are essential—we need something to show at the end of a project. However, we can sometimes get stuck in a cycle of churning out reports or other deliverables that aren't effective.

While planning your next project, ask your stakeholders the following questions:

• What type of information do you need at the end of the project?
• What decisions do you want to be able to make?
• What are the top three questions you need to be answered?
• In which ways do you best digest information?
• How could you imagine seeing these results?

If they can answer these questions, you can then create an effective deliverable that will get right at what they need. On the other hand, if your stakeholders cannot answer these questions, the best thing you can do is ask for feedback after you've delivered the results to continue improving.

Be okay that UXR might not be their favorite thing

As researchers, we got into user research because we love it. Talking to people, trying to understand them, bringing data together, and sharing information with others is exciting. However, it may not be everyone's cup of tea (or we'd have way too many researchers).

We are specialists, and not every stakeholder will love our specialty. The best we can do is show them how we can help. Because even if they don't love user research, they can appreciate it.

Overall, user research is meant to be collaborative, and involving colleagues as much as possible can be incredibly helpful to your process. By treating stakeholders as our users, we can demystify what they need from us and ensure we deliver the most compelling insights possible.