When Traditional UX Research Doesn't Fit

by Jeff Humble

Dear Reader,

Sometimes, that research phase just doesn't fit.

What can you do when everybody says no to the research phase?

Perhaps they have a reason for saying no. In many tech companies, a traditional research process can slow down the learning speed.

Research doesn't have to be upfront.

Upfront, traditional discovery research isn't the only way to do research. You can evolve beyond this problem-then-solution process.

Process models like Design Thinking and the Double Diamond make designers think that discovery always has to come first. Force-fitting a research phase at the beginning of every project won't earn you a trophy. In fact, it might be showing your managers that you don't understand how your company prefers to learn.

With a mental model of "research first," you may think your only option is to hide time for research in your projects while trying to meet your deadlines. Sure, there are ways to squeeze discovery in (see continuous research), but you can't always find the answer upfront.

Sometimes, users don't know enough about the context to provide useful feedback...especially when the idea is totally new.

"People have told us over and over again, they don't want to rent their music...they don't want subscriptions." -Steve Jobs in 2003

You can conduct research while you deliver. But first, you must let go of the idea that research always starts projects.

Everything can be a test.

rapid experimentation double diamond testing process

Rapid experimentation is another way to research that starts with solutions, and it helps you evolve to better research practices in organizations obsessed with speed and numbers.

Rapid experimentation is an agile approach to the product development process. With this approach, frequent experiments are deployed in an attempt to discover new, innovative ideas. Experiments can range in severity, from simple A/B tests to larger field experiments. -Product Plan

The experiment doesn't have to be coded or release-ready. It can be a scrappy prototype that tests the value behind your product ideas. The important thing is to test the value, according to the customer, before you jump to implementation details.

Here is what might be new in Rapid Experimentation:

You need to know how to write a good hypothesis
You need to create a lot of rapid prototypes
You need a way to measure the prototypes you're testing
You need to remember to analyze the results of the test
You need to be able to form insights from experiment data

These are the skills we teach in Designing Product Experiments: LIVE, and I've seen dozens of designers turn their design skills into experimentation skills.

Setting up an experiment takes time, but it's much faster than doing 20 rounds of upfront user interviews on an idea nobody understands yet. You can still supplement experiments with more traditional qualitative UX research to understand the "why" behind the experiment numbers.

Some scenarios where rapid experimentation can shine:

The idea you're working on is completely new
Upfront research is seen as slowing down learning
The team prefers to learn from quantitative data

Remember, when an idea is new, sometimes the only way to learn about it is to put it in customers' hands and watch.

Everything is an assumption until it's in the hands of a user. Find ways to test your assumptions early and often. Testing can potentially offer more realistic insights than traditional research can provide.

What do you think? Is rapid experimentation worth a try?