Assumptions are not research: know what you actually know

Tolu owns a busy hair salon in Ibadan. She's sure her customers want to book appointments online, so she pays for a booking website. Three months later, almost nobody uses it. Customers still send a WhatsApp message saying "Are you free by 3?"

When a designer finally talks to her customers, the reason takes ten minutes to find. Most of them don't plan a hairdo days ahead. They decide that morning, and what they want to know is simply whether someone is free now. Tolu hadn't been wrong about her customers being busy. She'd been wrong about what they needed, and she'd never checked.

This module teaches you to check. It starts with the most important research skill of all: telling apart what you know from what you only believe.

Words in this lesson

Everyone assumes. Designers check.

Assumptions aren't a sign of a bad designer. They're unavoidable. The moment you hear about a problem, your brain fills in the gaps: who has it, why, and what would help.

The difference between a guess and good design is what you do next. A designer writes those beliefs down and asks: which of these could sink the project if they're wrong?

Tolu assumed three things, and never checked any of them:

1. Customers plan appointments in advance.
2. Customers want to book without talking to anyone.
3. A website is the right place to do it.

The first one was wrong, and it made the other two irrelevant.

What people say and what people do

Nielsen Norman Group sum up one of the most important ideas in research as the difference between "what people say" versus "what people do", adding that the two are often quite different.

• Attitudinal research captures what people say. Ask Tolu's customers "Would you book online?" and many will say yes. It sounds modern, and saying no feels awkward.
• Behavioural research captures what people do. Look at how bookings actually happen, and you see WhatsApp messages sent on the morning of the appointment.

Neither kind is "better". You need both, but when they disagree, what people do is usually the stronger evidence. The next lessons teach you to gather both.

How many, or why?

NN/g put the second big distinction clearly: qualitative methods are much better for answering questions about why something happens, or how to fix a problem, while quantitative methods are better at how many and how much.

As a beginner designer, most of your early research will be qualitative: a small number of real people, and a lot of listening and watching. That's what this module teaches.

Map your assumptions

Here's a practical method for deciding what to research first. You'll do it at the start of every project.

Step 1: write every belief down

Write each assumption as a separate, specific sentence. Not "customers want convenience", but "customers decide on an appointment days in advance."

Step 2: score each one

For each belief, ask two questions:

• How sure am I? Do I have evidence, or is it a feeling?
• How bad is it if I'm wrong? Would the whole idea collapse, or would we just need a small change?

Step 3: put them in a grid

                   UNSURE                         SURE
            ┌───────────────────────┬───────────────────────┐
   BAD IF   │  RESEARCH THESE FIRST │  Double-check, then   │
   WRONG    │                       │  move on              │
            ├───────────────────────┼───────────────────────┤
   MINOR IF │  Learn as you go      │  Fine for now         │
   WRONG    │                       │                       │
            └───────────────────────┴───────────────────────┘

The top-left box, unsure and bad if wrong, is where your research effort goes first. For Tolu, "customers plan in advance" belonged there. Checking it would have cost a few conversations and saved three months.

Turn the risky beliefs into research questions

A research question is what your team needs to learn. It is not a question you ask a customer directly.

NN/g warn that vague goals like "learning about users" fail, and give a better example: "What causes customers to abandon the product?"

Notice that none of these questions contains the answer, and none of them mentions a website being good or bad. A research question should leave room for you to be surprised.

In lesson 2.3 you'll learn to turn research questions into the questions you actually ask people. They sound very different.

A worked example: a pharmacy delivery idea

A student, Emeka, wants to design a medicine delivery service for his estate in Enugu. His assumption map:

His three research questions:

1. What gets in the way when people in the estate need medicine?
2. How do people currently get medicine when they can't go out?
3. What would make someone trust medicine they didn't collect themselves?

Emeka hasn't designed a single screen, and he's already avoided building the wrong thing.

Common mistakes

The short version

• An assumption is a belief you haven't checked. Everyone has them; designers write them down.
• What people say and what people do are often different. When they disagree, behaviour is usually the stronger evidence.
• Qualitative research tells you why and how to fix; quantitative tells you how many and how much.
• Map assumptions by how sure you are and how bad it is if you're wrong. Research the unsure, high-risk ones first.
• A research question is what your team needs to learn, specific and without the answer inside it.

Try it yourself

1. Go back to the problem you explored in lessons 1.3 and 1.5.
2. Write down at least ten assumptions about it, each one a specific sentence you could prove wrong.
3. Draw the four-box grid and place each assumption in it.
4. Take the beliefs in the "research these first" box and write a research question for each. Aim for three.
5. Check each research question: does it contain a solution, or an answer? If so, rewrite it.
6. Save it all in your design-journal. Lesson 2.2 turns these questions into a plan.

You'll know you've got it when at least one assumption you'd have happily designed around now sits in the "research these first" box, and you can say exactly what would happen to your idea if it turned out to be wrong.