Ask anyone in the world of digital products about the value of understanding customers, and in all likelihood, they’ll gush about its importance. And yet, very often product teams report that they conduct little to no user research or usability testing during their product development process. 

But why? There are a number of reasons, but I’ll touch on a few that we at Nine Labs see most frequently.

“Research takes too long.”

Many research and design activities are in a constant push and pull with the ever-present Deadline. Sometimes The Deadline is a concrete thing driven by real-world restrictions (e.g. An impending trade show where a prototype will be needed), but just as often it’s an arbitrary date handed down from leadership. 

Deadlines are always a source of pressure and anxiety that encourages teams to indulge a bias towards actions and activities that result in the creation of something, regardless of whether that something is the right thing. When you’ve made something, at least you can hold that up as progress (have something to point to in an executive-level presentation).

Down the road, those teams often discover that the Something they made doesn’t suit customer needs, and they need to start over from scratch. Now, the true timeline for delivering a successful product is much longer and more expensive than if they’d taken the time to learn and understand first, and then build the right thing on the first try.

In order to counteract the force of a deadline, teams need to both schedule time for research from the get-go and exercise discipline throughout the project to avoid giving in to pressure from over-eager stakeholders. In situations where the deadline is relatively arbitrary, communication and flexibility are also important. If something critical is learned during the research process that seems likely to blow up the project timeline, team members must feel empowered to make the case to higher-ups that the deadline should be adjusted. A truly healthy company will be one where everyone involved is aligned on the value and risks of each step in the process, and where anyone can throw a flag when they see a problem.

“We’re not allowed to talk to our users.”

For industries that involve closely-protected intellectual property or sensitive data, risk-averse security policies can make it difficult for teams to start doing user research. Compliance officers may see mention of talking to outsiders about a product and immediately put the kibosh on a project.

In some cases, those with the most access to customers and prospects such as customer service or sales representatives may be over-protective of their clients, worried that contacting them too frequently to ask for “favors” like participating in an interview or usability test, may annoy them or exacerbate existing tensions.

Any change of the status quo in an established company comes with its share of resistance. A team that wants to create a research practice should expect a good amount of political and cultural maneuvering in order to achieve their goals. That can often require some lateral thinking.

A good first project for any new research team is to research the inner workings of the company itself. Identify all the key actors and deciders. Conduct interviews to understand the incentives, challenges, and motivations behind each stakeholder involved. Figure out what you can do to win over those deciders by demonstrating how you can help solve their problems as well as your own. You want to make it as easy as possible for each stakeholder to say “yes” to your proposal.

Lastly, while it can be tempting if you’re a systems thinker to try to tackle how things are done at the scale of the company as a whole, it always helps to start small. If you can’t get permission to do research on your flagship product, then propose a pilot where you can do it on a small project. Determine your success metrics early on and make sure you do all you can to measure the impact of research on the project. That can include things like sales numbers, System Usability Scale scores, or user adoption, but also things like developer satisfaction or a number of hours in meetings arguing over design choices.

“What if they give us feedback we don’t want to hear?”

It’s pretty rare to hear someone say this out loud, but it can hide out in the subtext of a lot of conversations. The sunk cost fallacy is powerful, and after spending millions of dollars and multiple years developing a product, research holds within it the risk of learning that a lot of time and money was wasted. This, of course, is why it’s best to do research before much time and money are invested, but most companies are not start-ups with a blank slate. Most companies already have products on the market, and in most cases, you’re starting to do user research in the middle of the action. Conducting research walks hand-in-hand with having hard conversations that might not make everyone happy.

Everyone also has their own ideas about what features should be developed, or what direction a product should take. If the existing company culture involves the person with the loudest voice or strongest opinion driving the direction of the product, user research can disrupt that way of working in a way that will ruffle some feathers.

The worst possible outcome of new research practice is to leave important stakeholders feeling upset or unhappy about what they’ve learned. That’s a recipe for having research deprioritized or skipped entirely in the future. To present research successfully, especially to people without much experience with it, you need to ensure that stakeholders walk away confident that the findings will help them and the company succeed. They also must be able to clearly see the next steps, whether those involve further research or a specific design direction to take.


Starting to incorporate research into your product design process can be difficult, but can also provide enormous value to your company. In an article by McKinsey & Company we learned that “companies that rely more heavily on consumer data were 23 times as likely to gain more customers, 19 times more likely to achieve ‘above-average profitability’ and 6.5 times as likely to retain customers”. That’s data that speaks to us!

Not exactly sure how or where to start implementing UX Research? Nine Labs can help.

About Cathy Fisher


Cathy Fisher is the Senior User Experience Designer at Nine Labs. She’s worked at startups and in enterprise healthcare technology for the past decade, wearing the hats of designer, developer, and manager as needed. She’s worked intensively on building design systems, developing organizational design maturity, and mentoring other designers. Her passions include weird inside jokes, developing handy tools, and naming icons correctly.

Cathy received her MSI in Human-Computer Interaction and her BA in Film from the University of Michigan. Follow Cathy Fisher on Medium and connect with her on LinkedIn.