Say you’re starting a greenfield project, or you’re redesigning a legacy app. The product owner gives you some high-level goals. Lots of ideas and questions are in your mind, and you’re not sure where to start.
Hypothesis-driven design will help you navigate through a unknown space so you can come out at the end of the process with actionable next steps.
Ready? Let’s dive in.
Step 1: Start with questions and assumptions
On the first day of the project, you’re curious about all the different aspects of your product. “How could we increase the engagement on the homepage?” “What features are important for our users?”
As a designer, you’re naturally curious and have tons of questions about the product. It’s important to pause and think about the questions and assumptions you have before jumping into solutions. It’s easy to come up with design ideas, but it’s hard to solve the right problem. Building a product with lots of unanswered questions increases risk.
To reduce risk, I like to take some time to write down all the unanswered questions and assumptions. So grab some sticky notes and write all your questions down on the notes (one question per note).
I recommend that you use the How Might We technique from IDEO to phrase the questions and turn your assumptions into questions. It’ll help you frame the questions in a more open-ended way to avoid building the solution into the statement prematurely. For example, you have an idea that you want to make riders feel more comfortable by showing them how many rides the driver has completed. You can rephrase the question to “How might we ensure rider feel comfortable when taking ride,” and leave the solution part out to the later step.
It’s even more valuable to have your team members participate in the question brainstorming session. Having diverse disciplines in the room always brings fresh perspectives and leads to a more productive conversation.
Step 2: Prioritize the questions and assumptions
Now that you have all the questions on sticky notes, organize them into groups to make it easier to review them. It’s especially helpful if you can do the activity with your team so you can have more input from everybody.
When it comes to choosing which question to tackle first, think about what would impact your product the most or what would bring the most value to your users.
If you have a big group, you can Dot Vote to prioritize the questions. Here’s how it works: Everyone has three dots, and each person gets to vote on what they think is the most important question to answer in order to build a successful product. It’s a common prioritization technique that’s also used in the Sprint book by Jake Knapp—he writes, “The prioritization process isn’t perfect, but it leads to pretty good decisions and it happens fast.”
Related: Go inside design at Google Ventures
Step 3: Turn them into hypotheses
After the prioritization, you now have a clear question in mind. It’s time to turn the question into a hypothesis. Think about how you would answer the question.
Let’s continue the previous ride-hailing service example. The question you have is “How might we make people feel safe and comfortable when using the service?”
Based on this question, the solutions can be:
- Sharing the rider’s location with friends and family automatically
- Displaying more information about the driver
- Showing feedback from previous riders
Now you can combine the solution and question, and turn it into a hypothesis. Hypothesis is a framework that can help you clearly define the question and solution, and eliminate assumption.
From Lean UX
We believe that [ sharing more information about the driver’s experience and stories ]
For [ the riders ]
Will [ make riders feel more comfortable and connected throughout the ride ]
4. Develop an experiment and testing the hypothesis
Develop an experiment so you can test your hypothesis. Our test will follow the scientific methods, so it’s subject to collecting empirical and measurable evidence in order to obtain new knowledge. In other words, it’s crucial to have a measurable outcome for the hypothesis so we can determine whether it has succeeded or failed.
There are different ways you can create an experiment, such as interview, survey, landing page validation, usability testing, etc. It could also be something that’s built into the software to get quantitative data from users. Write down what the experiment will be, and define the outcomes that determine whether the hypothesis is valids. A well-defined experiment can validate/invalidate the hypothesis.
In our example, we could define the experiment as “We will run X studies to show more information about a driver (number of ride, years of experience), and ask follow-up questions to identify the rider’s emotion associated with this ride (safe, fun, interesting, etc.). We will know the hypothesis is valid when we get more than 70% identify the ride as safe or comfortable.”
After defining the experiment, it’s time to get the design done. You don’t need to have every design detail thought through. You can focus on designing what is needed to be tested.
When the design is ready, you’re ready to run the test. Recruit the users you want to target, have a time frame, and put the design in front of the users.
5. Learn and build
You just learned that the result was positive and you’re excited to roll out the feature. That’s great! If the hypothesis failed, don’t worry—you’ll be able to gain some insights from that experiment. Now you have some new evidence that you can use to run your next experiment. In each experiment, you’ll learn something new about your product and your customers.
Building a product that people love requires continuous learning. You might not get it right the first time. For example, you found that people feel more comfortable when they have access to the previous experience of a driver, but what about a new driver with no history?
What other information can you show to make riders feel safe and comfortable? That can be your next hypothesis. You now have a feature that’s ready to be built, and a new hypothesis to be tested.
Design is a never-ending process, and through hypothesis-driven design, it gives you valuable insights on what you should do next.
We often assume that we understand our users and know what they want. It’s important to slow down and take a moment to understand the questions and assumptions we have about our product.
We don’t know what we don’t know. If we continue to answer the questions we have and constantly test the hypotheses, we build a large database of insight about our users and their behaviors. If we don’t, the assumptions will accumulate, and we might end up spending months building a feature that users don’t need.
After testing each hypothesis, you’ll get a clearer path of what’s most important to the users and where you need to dig deeper. You’ll have a clear direction for what to do next.