User research is an integral part of product design and development. Still, user researchers often find that their results are met with skepticism or second-guessing by other stakeholders involved in the project. Even when they have tested a product with thousands of hand-picked participants in a perfectly moderated user test, it often takes one unobjective comment to discard their long hours of work as something “unreliable”, “unsubstantial”, or “debatable”.

Any seasoned user researcher will confirm that user research is not just about the findings and insights. It’s also about building and managing relationships. To ensure that user insights are at the center of product decision-making, you will first need to win the trust of your project’s key players. That means turning designers, engineers, and product owners into allies. Let’s take a look at 4 of the most common stakeholder biases that researchers face, and how to turn skepticism into confidence.

Stakeholder bias #1: “The study participants are not our real customers.”

As a user researcher, it’s important to clarify to your stakeholders that the terms “customer” and “user” are far from being synonyms, but actually represent two very different roles. A customer can be a company or a cumulative of multiple departments and roles. Often, an employee from the purchasing, IT, or HR department will represent the customer and is the one responsible for choosing the product you’ll be conducting research on, setting it up with your help, rolling it out, and implementing it within the organization. We further differentiate between customers as “power users” (usually administrators), who know all the workarounds and alleys of your product, and other customers that no longer play a part as soon as your product has been implemented in the company.

Unlike the customer, the user is the person who will actually work with your product on a regular basis and has probably little to no information on it or the behind-the-scenes decisions. The user’s primary goal is to get a particular job done by interacting with the product. There is a reason why it’s called user research. Instead of relying on retold pain points from the customer’s perspective, we want to get first-hand insights from our end users to really understand and solve their actual problems. Therefore, it might not be the best idea to invite your customer to usability tests as most of them won’t be able to share reliable information on the pain points.

Tip: Take the time to explain the difference between customers and users to your stakeholders and suggest involving them in a different context where their strategic direction and high-level insights can best inform your efforts.

Stakeholder bias #2: “The selected participants don’t have the necessary experience to use our product.”

Before diving right into problem-solving, you first need to think of the key jobs your users want to perform. The reality is that they will have to get these jobs done with or without the product in question. That’s because Jobs to Be Done are product-agnostic, remain quite stable over time, and do not require any upfront experience with a particular solution. As Jim Kalbach, author of the “Jobs to Be Done Playbook”, said: “People employ products and services to get their job done, not to interact with your organization.”

Secondly, reiterating on the differences between users and customers, an end user interacts with your product on a regular basis. If your user is a shift worker submitting their working hours once a month to their manager, you can’t realistically expect them to remember the location of every button and every interaction they once performed. Your product needs to be intuitive enough so that even a complete newbie can find their way around. Therefore, unless you are looking into the experience of power users, your research study participants do not require any prior experience with the product.

Tip: Make sure you know and understand the job your user needs to perform before you start the user research process. When faced with pushback, emphasize the qualities of intuitive design to justify why your chosen participants don’t need any product experience beforehand.

Stakeholder bias #3: “This was my least favorite design concept. How is this the winner of the study?”

You might have heard this statement from stakeholders who were against user testing in the first place as they were convinced that their preferred direction was the correct one. Most of the time, these kinds of stakeholders just want some user testing done to know if the product is generally fit for usage, but don’t really put emphasis on the specific user experiences that the testing could reveal.

It’s not uncommon that stakeholders display frustration after you present them with the user research findings, especially if they requested research to confirm their initial thoughts or as a box-checking exercise. They will likely not know what a research question is, and believe that user research is an obstacle they’d eventually have to overcome. And if you’re honest with yourself, they were likely not properly involved in the preparation phase of your shared research study.

It may seem tempting to want to take over and create well-phrased research questions yourself without involving your stakeholders. But, if you really want your counterparts to comprehend the process, you should guide them through the journey of user research from the very start. You may even choose to shadow them while they design the product to help pinpoint how a research question comes to life. As matter of fact, you need them on your side if you want to see your research findings integrated into future design directions.

Tip: Instead of switching into defense mode, try empathizing with your stakeholders. You are most likely standing in front of a person who is unfamiliar with user research. They may also feel frightened that the results might bring overflowing backlogs and iterations on aspects that have already been signed off. Try involving them from the very beginning and you’ll see their worries disappear along each step of the way.

Stakeholder bias #4: “We need you to conduct five interviews a week.”

There is a prevailing opinion that user research solely consists of interviews. What many stakeholders may not know is that there’s a plethora of different UX research tools and approaches suitable for any requirement, experience, and product development stage. Of course, you may not have the deep product expertise of your stakeholders, but in the end, you’ll be the one bringing the research expertise to the table. Involving them in your process is important, but choosing the right approach and recruiting the appropriate users is up to you.

Tip: Dealing with stakeholders holding a high position and expertise might be intimidating, but remind yourself that unlike them, you’ve already conducted user research in the past and know which methods will result in reliable findings. Hold your ground!

As you may have noticed, user research is not about winning, losing, or insisting on one’s opinion. It’s rather a synergy of teamwork, collective knowledge, and effort to reach a common goal. It’s all about communication and building trust in the first place. If you are lucky, you’ll even see the product come to life and accompany it every step of the way.