How to Make Your UX Research Findings Resonate With Stakeholders
The 3 questions that can make a huge difference
Your user research may be missing a step that makes a huge difference to your stakeholders.
You have followed the proper steps. You’ve gathered enough users, set up usability tests, and done data analysis.
But have you thought about how you’re going to present your data to your stakeholders? It’s a step that many skim over, but it can be crucial in making presentations that drive stakeholder action.
To start, you need to re-examine your approach.
The approach many Junior UX’ers take
I got my first lesson in presenting to stakeholders when I was told that my presentation was too long.
“You could’ve cut out a lot of the methodology section.” My mentor said, but what she said next stuck with me to this day.
“We trust that you know what you’re doing.”
My presentation had been structured like I had been taught during my formal design education.
I had laid out my entire process in these sections: describing the larger context, the problem, the methods, analysis, and then talking about the conclusion.
This is what’s often known as exploratory analysis, or the process of “Turning over 100 rocks to find 1 or 2 gemstones.”
It’s great for breaking down the problem during design thinking, but that may not be what you want to show your stakeholders. They usually trust you to make the right decisions about steps along this process.
So what should you show instead? That’s where explanatory analysis comes in handy.
Exploratory vs Explanatory analysis
Explanatory analysis is the process of deciding what to do when you want to communicate something specific (like those gemstones) to an audience.
And it’s a crucial step in presentations for one reason: figuring out your hierarchy of issues.
If your boss has to run to another meeting, or if the lead developer is out sick that day, how would they sum up this meeting?
More importantly, if your boss was only going to say yes to one or two changes (and refuse the rest because of time/budget constraints), which ones would you want them to say yes to?
Those are the questions you will figure out as you conduct explanatory analysis. In addition, those are the questions or steps that stakeholders most often care about, rather than the specific research methods that you used to get there.
So if that’s what stakeholders care the most about, and what they’ll take with them after the meeting, why not structure the presentation around this?
How to do explanatory analysis
So how do you do an explanatory analysis? According to Cole Nussbaumer Knaflic, author of Storytelling with data, it’s simply a matter of answering 3 questions:
- Who are you communicating with?
- What do you want your audience to know or do?
- How can you use data to make that point?
Let’s go through this one by one.
Who are you communicating with and how well do they know you?
Hint: it’s not everybody.
If you’ve ever encountered a client that says that “their product/app is for everybody”, it’s oftentimes a way of saying that they don’t know. It’s the same thing with this.
Trying to target general audiences, such as “all stakeholders”, will often result in muddled communications.
For example, what if your team consists of developers, analysts, and other highly technical people, but the product owner/manager comes from management/marketing/sales?
It would be incredibly difficult to have both highly technical and simple communications in one presentation that would be coherent for both audiences.
Instead, you might want to consider two different presentations with two meetings: a simple overview for less technical folk, and a second meeting where you dive into the specifics.
The other thing to consider is how do they perceive you. Is this an executive that you’re presenting to for the first time? Is this your team member that you regularly eat lunch with? That sort of thing will help you determine how much of an introduction to the project/research/etc. you might have to give.
What do you want the audience to know or do?
As UX Researchers and Designers, we are not usually high up on the decision ladder. This means that a lot of what we need to do at times is to convince others (such as executives) to make certain choices.
But if you don’t spell it out beforehand, you might end up in a scenario where an executive just asks you what to do about something on the spot (it’s happened to me before).
So what actions do you want them to take?
Rather than having them just look over the data and go “that’s interesting”, make them think about decisions and other actions you might want them to take.
Of course, you shouldn’t force them to make decisions on the spot, but I’ve found that some of my more successful presentations have resulted in executives going “Hey, can we schedule a meeting to talk about X?”
So if you know what you want your audience to take action on, then you can move on to the next step.
How can you use data to make your point?
This is heavily reliant on the first two questions, so the easiest way to talk about this is to use an example.
Imagine you’re giving a presentation to talk about the design changes that need to be made to a website. You know that the primary audience for this is going to be the product manager and owner, as they’re just joining the team and they need to be caught up on the project.
You want them to know about the current places users are getting stuck or problems that users face as they try and complete tasks on the website. By allowing them to know the major problems, they’ll be able to more effectively address them in those meetings.
How would you use data to make your point? Most likely by not touching upon too many specific usability issues: you don’t want to overwhelm them when they’re still trying to learn about this project.
Instead, the data you might want to seek out are current metrics: are there any metrics that are lacking (such as poor user retention, long time on task, etc.)? Start with that, and then you can lead up to some examples of poor UX.
For example, you might start by talking about a poor metric (such as a high abandonment rate as part of the checkout process).
After that, you might transition into a specific page of the checkout process, pointing out a number of the UX issues that exist on that page without going too far into detail in them.
That would likely result in them having a better understanding of the types of issues and reasons why this occurs without diving too far into the specifics.
Sometimes, this may be the right level of data for an audience. Other times, as you’re presenting details to a more technical audience, you may want to spend more time on different details.
But these questions may help you figure out the best type of approach to storytelling with your data.
Storytelling with data
Part of being a UX professional means that you advocate for your users.
This is why we try to understand the user’s experience, gather data on them, test new prototypes, and do all that sort of stuff with them.
So we should make sure that the user’s view is not lost as we talk to our stakeholders.
One of the easiest ways to do that is to think about what story you want to tell with the data.
People remember stories, and they can also be driven to action by them. So spend a little time thinking about what story your research tells.