Why bother? Why do I need user research?

Are you confident that:

• you’re solving the right user problem,
• know what users need to solve their problem, and
• that your solution will actually work?

If so, great news: you don’t need user research. If you aren’t confident in your answers to these three questions then user research might help you answer them.

Where does user research fit in with product development?

User research helps you increase the expected value of the product you ship to users. It does this by filling gaps in your understanding of your users’ behaviour.

• Let’s start with a way to frame product development:
  • The goal of product development is to create value for the organisation and its users.
  • It does this by making changes to the product.
  • The product changes are intended to make a positive impact on user behaviour.

Product changes can be thought of as bets

• So, you could say that building products is about placing bets. You’re not certain whether your product change will actually make a positive impact.
  • When you place a bet you stake some money, based on your belief about the outcome of an event. Maybe you believe Accrington Stanley will beat Liverpool in the FA Cup. If you’re right, you get more than your money back. If you’re wrong, you lose it. (In case you’re not familiar with the example, Accrington Stanley are very unlikely to beat Liverpool.)
  • Similarly you can invest effort in building some product change. You base your investment on your belief that users will like it and it will perform well. If you’re wrong about what users will like, you’ll have wasted that effort.
  • If you’re not confident whether Accrington Stanley are likely to beat Liverpool then you’ll probably want to do some research into how each team is playing.
  • Let’s say you find out that Liverpool are a much stronger team than Accrington Stanley. You might decide to place a much smaller bet on Accrington Stanley. Or you might decide to place an entirely different, stronger bet - such as Norwich City beating Ipswich Town.
  • But whether your do research or not, you might still lose your bet.

User research can improve your bets

• So let’s assume your team has a clear goal. You have a metric that you want to move. In the betting analogy, this metric is equivalent to the money that is paid out when you win.
• Let’s assume your goal is some kind of user behaviour. And the behaviour creates value for them, and for the business. For example, click ‘Add to cart’.
• You want to make a change to the product that causes a change to user behaviour. For example by changing the colour of the button from red to green you increase the proportion of users that click ‘Add to cart’.
• So you do the research to understand which product change will influence user behaviour in the way that you want. You want to make the right bets and increase your confidence in those bets.
• Without useful user research, you might make a product change that doesn’t change users’ behaviour the way you expect. You invest the development effort on this bet and it doesn’t pay off.
• Useful user research is also useful while you’re building. It helps the team understand the purpose of what’s being built.

As a tangible example, look at an A/B test: https://goodui.org/leaks/airbnb-discovers-a-better-calendar-picker-component-from-this-ui-experiment/

So how do I find the product change that induces that change in behaviour?

When placing your bet, there are different types of risk. You want to be able to answer these questions with enough confidence.

In a betting analogy, you could ask:

• Is this the right bet to take?

• How likely am I to win the bet?

• Your gaps can be expressed as:

  • Which product to ship
  • What benefits it should offer
  • How valuable users find it

Some people frame it as:

• Build the right thing
• Build the thing the right way

Or:

• Discovery
• Validation

But I’ll follow this structure:

• Why solve this user problem?
• What solution should we choose?
• How will it be solved?

Do I need to do three bits of research each time?

No.

Each of these questions is independent. Remember that if you’re already confident in your answer to any of these questions, you don’t need to do research. If you genuinely have these questions, then get answers you can believe in.

Once you understand a user problem, know what will solve it and know that your solution will actually work, you can be more confident that your bet will pay off.

The One True Way

A common error is to think that the goal is to do things the ‘right’ way:

• If the ‘business’ is driving some terrible idea from commercial needs rather than solving customer problems, the goal of the product team is not to evangelise the One True Way. You do not need to tell them that ‘Google does user research’ or Teresa Torres says we should speak to users.
• If you try to show them that the whole basis for the project is nonsense you’ll (1) be back at square one if you’re successful, or (2) more likely fail to convince them and build up mutual resentment along the way. I see this all the time and it’s ineffective.
• Instead, your goal is to create the most value for the business and customers. This might mean executing the best you can on a bad plan.

Execute on a bad plan

Executing well on a bad plan isn’t necessarily the right thing to do, but I’ve found it to be the least worst option:

• By executing well, you build trust with stakeholders. They spend most of their day thinking of things other than you. So if you can be trusted to take something and run with it, you’ll build trust.
• As you execute, you should still be clear about where the user needs have or haven’t been addressed.
• Once you’ve successfully executed you can look at your results. If the results were positive then that is a good thing. User research is an investment, so you should minimise it. If the results were negative then you finally have a convincing argument for why you need user research: you’re capable of shipping, but users don’t find value in what you ship.