So Your Stakeholders Don't See the Value of UX Research

Turning Mundane UX Research Requests into Product-Altering New Worlds of Discovery

· uxresearch,thebusinessofUX,Working with Clients


One of the frustrations UX Researchers often face is working with stakeholders - fellow team members, executive management, investors, etc. - who “do not understand the value of UX Research.”

As common a complaint as this is among UX Researchers, it’s not all that surprising to encounter, and it is surprisingly easy to overcome. If you know a few “tricks”.

Common Objections

Some of the most common objections I’ve heard in my own work, and from colleagues in the field, include:

We don’t need to test our concept, we know what our customers want


We don’t have the time/money to do this during development


This is just a proof of concept; we’ll get customer feedback later


We already know what we’re trying to solve for


We can learn what we need to learn from the metrics

Critically, none of these objections indicates a “lack of understanding” about the value of UX Research. Rather, each of them more accurately reflects a decision to prioritize other needs first.

This is hugely important, because as UX Researchers, it fundamentally alters the nature of our challenge: we’re not being asked to educate, we’re being asked to convince.

The Junior Consultant and the Cereal Box

So, how do you convince someone that your work is important, that it will make customers happier, help the business succeed, bring joy and celebration to all who hop on board the Research Bus?

When I’ve hired UX Researchers and consultants for my agencies in the past, I’ve always asked some variation of the following question during the interview process (usually very early on):

“Sally, a senior Product executive at Succulent Cereals, is reviewing two designs your team has presented for their new product, Saguro Flakes. One of the designs is obviously - to you and the team - superior. It tests better with the audience, consumer understand to labeling more clearly, it’s easier to produce; everything about it is just better.


Sally disagrees, and wants to go with the (clearly inferior) design. She is absolutely firm on this. undefined


What do you do?”


The point of this (mildly amusing) scenario is to immediately understand how the potential hire views the situation. Is this a matter of presenting more evidence? Does Sally misunderstand something; is she “stuck” or “biased” or “not seeing the value” inherent in the “superior” design?

Does the situation call for more testing? More data? More convincing evidence?

Those things might eventually help, but immediately falling back on that angles misses the forest for the trees.

There are lots of correct ways to handle this situation, but they all begin by recognizing the same point:

This is not a data problem; this is a relationship issue


Understanding Your Stakeholders’ Priorities

Hearing some of the objections above, we are naturally inclined to attempt a counter-argument. For aach of those objections, there is clear, concise, and factually correct response. And, if you deliver them with enough confidence, the response might even shut down the objection, and overwhelm the objector.

And this would be wrong.

Instead, your role - as a UX Researcher, as a team member, and as a human - is: to empathize.

When it comes to working with stakeholders, many UXRs seem to take the skill they’ve spent decades developing and improving - so we can deliver better research, produce deeper insights, and connect meaning to action - and throw it out the window.

Look at each of those objections, and think: "what is the customer (my stakeholder) trying to say to me?"


We don’t need to test our concept, we know what our customers want

This person seems to be highly confident they understand their customers’ needs. Perhaps they do? Perhaps they have insight (maybe from years of experience) that could enhance your own understanding of the customer. This person is inviting you to ask deep questions about the customers they know so well, and likely would love to tell you what they know. Ask.


We don’t have the time/money to do this during development

The stakeholder has real concerns about the timeline and/or the project budget. They are likely being held to account for someone else’s expectations (more senior management; a board of directors; investors). A conversation about risk-reduction and the cost of getting a product decision wrong, while objectively accurate, may only inflame their fears/concerns.

Instead, as about those deadlines. Invite some conversation about the budget. What are those constraints being shaped by? Where is their wiggle room, and where are the constraints rock-solid?


This is just a proof of concept; we’ll get customer feedback later

I often hear this from people working in a startup context, where there is enormous pressure to prove that the thing can be built. Concerns about the customer experience often run secondary, because users are not the customers - investors are.

This is an opportunity to learn more about the fundamental structure of the business, the tensions driving the product forward, and to ask questions about the timeline and metrics that are being used to judge success.


We already know what we’re trying to solve for

Assume you are dealing with someone who has a clear idea, at least in their own head, of what the problem space looks like, and get them to define it for you. Are there areas you've missed? Are they using different language from you to define the same basic challenges? What outcomes are they looking for that will tell them that they've solved the problem correctly?


We can learn what we need to learn from the metrics

Check this person for head injuries.

Just kidding.

While there are definitely people who will confuse quantitative usage metrics for good UX research data, changes are better that they've had experience launching product features to a large test audience, and relying on usage data to tell them which implementations are working best. If so, they've got their eye on the big picture (the customer KPIs that matter to the business), and you can pick up a lot of detailed and useful information from them by asking questions about those.


It's the Relationship that Matters

The end goal of all of these lines of inquiry is not to fix the immediate conflict between your desire to have UX Research "better understood" or "more appreciated."

To goal is to build better relationships with the people who are in a position to advocate for your research more, down the road.

You are playing the long game.

You're juijitsuing your current roadblocks into powerful points of leverage for your future endeavors.

Building those relationships takes time, care, effort, and empathy.

Just like great UX Research.


Want More of This? Subscribe: