How to Overcome 8 Common Objections to UX Research

Published May 3, 2021

Whether you’re fresh into the ideation stage of a new business or you’re working on the next big feature, it’s important to have a clear understanding of your users’ experience. Not being aligned with how a user interacts with a product is one of the key reasons why apps fail. You may already know the importance of validating your work through user-focused research, but find that when you suggest it as a way to gain insight into your customers, you’re met with resistance from your team. Often, this is because the very thought of research sparks visuals of hundreds of test subjects engaged in psychology experiments — even when it’s not.

To convince your team that research is worthwhile you need to help them understand how the information you collect is a goldmine to a product team, and quite frankly can mean the difference between a product that creates value for its users and one that fails. I’ve been a designer for a long time, I have certainly been there. But once I learned how to sell UX research, it became a lot easier to convince people that user testing is worth it. Here are some of the most common objections I hear and how I overcome them.

1. Research is expensive

This is likely the most common object you’ll hear. Let your team know that you plan to keep it simple. User research doesn’t have to require a lab and multiple test participants. You don’t even need to hire someone with a degree in research to do it. It can be as simple as taking an afternoon to meet with a handful of your targeted users to ask them some well-planned questions.

This can be done by you and is only as expensive as a few hours of your time to plan and facilitate. Your team might think they are solving a short-term problem (ie. saving on costs), but when you compare the cost of the hours needed to retroactively correct the issues that have blindsided you, research is incredibly cheap.

“When you compare the cost of the hours needed to retroactively correct the issues that have blindsided you, research is incredibly cheap.”

After all, the best way to save money is by fixing problems before they are integrated into your product because once they’re there, you could be constantly working around that constraint.

2. Research is slow

The misconception that research takes a long time comes from not seeing just how simple and scalable user research can be. Depending on your capacity, it can be done in just a few hours of getting together with a user and asking them some focused questions. When it comes to validating your assumptions to ensure you create a valuable end product, talking to just one person is better than talking to none — but I recommend talking to more.

Having a set plan is your key to success here. If you present an outline of what you want to ask your user and propose a reasonable time frame to complete the interview, you can convince your team that research won’t set you back, even if you have a short deadline.

3. Research is hard

If you’re met with the objection that research is a difficult and complex process, let them know how simple your process will be and that you want to start with asking users these four questions to a targeted group of people.

  • What’s working for you?
  • What’s not working?
  • How would you improve your experience?
  • How would you make the perfect product to solve your problem with no cost or deadline restraints?

These questions will allow you to listen, discuss, and see more clearly the needs of your user. Once you’ve mastered asking these discussion generating questions, you can scale your research to be more thorough. If you’re looking for guidance on how to do this or want to outline the process clearly to your team, we wrote a quick-start guide to user testing.

4. We know what we need to build

If your team has an idea of what needs to be built, you should still pitch customer-centric research as a means to validate those assumptions. After all, if you build solutions based on your own experiences, your vision for the product could be filled with biases and blind spots.

What feels like the right solution might miss the mark with the way your users think. I’ve personally been in situations where I worked with a specific product for years, only to have my beliefs completely shattered within five minutes of watching someone try and use the app. Had I stopped to check my assumptions periodically while building, The product would have found greater success early on and saved the company a ton of money had we built the right solution first.

5. We can do it later

Imagine designing a city without first deciding where the buildings, homes and parks will be. You’ll end up having roadways to nowhere, you’ll be contained by streets, and you citizens will complain that your highway runs through where they wish they had park space.

Asking for input after the fact and heading straight into the design is a sure way to build constraints into your product, leaving you two options: 1) build around them or 2) pay the costs to fix them.

So pitch spending time with your users as a way to yield a deeper understanding of their needs. Their needs will be the blueprint that will guide you to make a product that resonates with them the first time around.

If you don’t you’ll be forced to spend money to figure out what’s going wrong, then spend money to work around the restraints in order to fix it. But some of these things may not even be fixable. Things can get so baked into a product they cause chaos forever.

6. Our users have been asking for X feature, let’s just build it.

Your users are full of great ideas and you might have determined the feature they want. But do you know what the problem is your user wants that feature to solve? Ask this question to your team and tell them that research will tell you exactly how to build a solution that aligns with your user’s wants and needs.

Feature requests can be incredibly broad. But it is the intricacies of the feature that hold the true value for the user. So by consulting with them, you can narrow down the specifics for what they want within the feature. This will avoid them coming back complaining you didn’t add date filters to that new search feature they asked for.

7. We’ve got analytics and data, we don’t need research

Analytics are crucial to have, but it only tells you half of the story. Sure it can tell you where users get stuck and then drop off, but no analytics can give you an in-depth look into WHY.

You can hypothesize about what the data you have gathered is telling you, but until you get insights from the people who are using your product, you’ll never fully know what is leading to the problem. Research doesn’t replace analytics and data, it is the next step in identifying the problem and determining how to solve it.

8. We’ve had some people try our apps and tell us what they think, we’re good.

Your team is ahead of the curve if they’re already out there talking to people. But good research never ends and the quality of the questions you’re asking matters. Jared M. Spool of Center Centre – UIE explains that the solution to creating a great user experience is found in “exposure hours. The number of hours each team member is exposed directly to real users interacting with the team’s designs or the team’s competitor’s designs. There is a direct correlation between this exposure and the improvements we see in the designs that team produces”.

This is an opportunity to let your team see that there are many types of research that yield different insights. The idea is not to just conduct research once and be done but to build it into your culture and refine the quality of the research as you go.

The Takeaway

Product teams are often focused on the now and what needs to be done to move towards launching a product as quickly as they can. They are unaware of what exactly user-research is and how cheap, efficient and effective it can be.

But with a little of your guidance, you prove that user research is worth it and help naysayers see how consulting with your users ensures you never step off a curb without looking both ways.