Most UX teams live every day with the anxiety that they don’t truly know what their users want and need. They think they know. They build features and experiences that they hope will satisfy user needs. They may even do some usability or user acceptance testing to work out the bugs and make sure what they built works as intended.

In our experience, though, most organizations don’t have the time and resources to do the type of in-depth research that ensures you’re solving the core problems of your users.

After all, what’s a product worth if it doesn’t help a real person solve a real need in the real world?

Over two blog posts, we’re answering two fundamental questions about UX research - why to do it and how to do it.

Part 1: Why do UX Research

The most important question in any research project is to ask yourself why you’re doing research in the first place.

What problem are you trying to solve?

Who is the research going to help?

Where, when, and how do you anticipate using the insights from your research to improve the product?

You may not have answers to all these questions right away, but simply by asking them you’ll uncover a lot about whether or not research is the right investment to make right now.

We’re in a unique position at Drawbackwards of advising clients at every stage of the product development process. Some are just getting started and trying to better define the problem they’re looking to solve for people. Others are mature products that are looking to refresh and redefine what they offer.

Regardless of where they are in the process, there are three common reasons that clients typically ask us to help them with UX research.

Reason #1

We have to justify investments that we believe will improve the product.

Of all the reasons to do UX research, this might be the weakest but most common. Many product teams struggle to get a consistent budget for anything much more than keeping the lights on. Yet most product teams know the key areas where their product needs the most help.

That’s why research is often used to justify what the product team thinks it already knows. It’s seen as a tool to “sell” the need for improvements to management and those holding the purse strings.

There are two problems with this approach:

1. It’s never a good idea to go into research loaded with assumptions. You’re much more likely to only pay attention to what you’re looking for and miss valuable insights in what you didn’t expect (and haven’t thought to budget for).
2. You’ll likely uncover more than you bargained for. On the other end of the spectrum, you may open a Pandora’s box of problems you didn’t know you had, which can draw the wrong kind of attention from the C-suite and distract everybody from the core problems you set out to solve.

That said, there are times when it makes sense to do research to help justify additional investments. Just be sure that you’ve narrowly defined the problem you’re trying to solve and you go into the research with an open mind to what you may uncover that you didn’t anticipate.

Reason #2

We need to understand the reasons behind a problem at a deeper level.

We’re all swimming in a lot of data. Most products and services have analytics that can track every step of the user or customer journey.

What those passive analytics don’t usually capture is the “why” behind the behavior. That’s where thoughtful and thorough user research can play a valuable role.

It usually takes just a couple of times around the block of creating solutions that don’t eventually work before a UX or product team learns the value of doing research before building solutions.

Exploratory research helps you uncover the deeper motivations of your users and customers, understand their environment, empathize with their core real-world problems, and ideate real solutions that have a better chance of success.

Unfortunately, we’ve seen too many teams kick the research can down the road and assume they can keep taking stabs at solutions before they put it in front of actual users.

Problems don’t always just jump off the page to designers and developers. They need to see the user in action to understand the context in which the solution will exist. Then, they’ll have what they need to make the tweaks that will take a product from good and functional to great and delightful.

Don’t underestimate the power of sitting down with a user to chat about the problem you’re trying to solve even before you have a solution to offer.

Reason #3

We want to identify surface-level UI problems so we can iterate quickly.

There’s absolutely nothing wrong with quick usability testing as a pulse check while you’re iterating. In fact, we often build light and simple UX research into two-week design sprints for clients. It’s a great way to make sure what you’re building works as intended and helps you adjust quickly if it doesn’t.

But don’t let that lull you into feeling like you’ve got everything covered. You’ll still want to make sure you have your bases covered with in-depth research that has identified the core problems and characteristics of your users, and you’ll want to make sure the quick tests you did stand up over time.

Keep your finger on the pulse with quick checks but also remember that nothing beats real-world experience and seeing your product or service in the wild.

For best results, take a blended approach.

We’ve worked with clients on a wide range of problems through the years and we’ve seen a lot of motivations for doing research. Some clients are just starting to understand the problems their users face. Others are digging for new understandings.

In each scenario, we look at the underlying problems and make sure that we’re designing research that uncovers the needs of the users, not just scratches an itch for the product or business team to feel better about decisions they already made.

That’s why we’re big proponents of a mixed approach. Mixing your research methods helps you gain a more holistic view of your product or service and the people who rely on it. Sticking to just one approach will leave you with the impression that the trunk is the only part of the elephant that matters.

For more on how we make sure we use a mixed method approach, check out our next post on how to do UX research.

If you’re interested in having an experienced and trustworthy guide to help you on your research journey, start a conversation and let’s talk about how we can work together.