Reduce risk in your product development with Hypothesis-Driven Design
Releasing new products and features is often risky business. If you don’t solve the right problem or meet your users’ expectations, it can have detrimental consequences to your company’s success.
From experience, I’ve learned that new releases are most risky when they’re build on an equally unreliable foundation — assumptions.
We tend to think that we know what people want and need, but sadly, I’ve learned that assumptions do not work like a God-given sixth sense or a guiding light of clarity. In fact, we’re more often wrong than we’re right because we use ourselves as the golden example or make guesses about how others think.
You probably know how important user research is for the development process. But hypothesis-driven design (HDD) is the step before your user research. It’s a scientific approach to help you understand the problem you’re trying to solve as well as a way to gain extensive knowledge on a subject in a short time frame.
HDD will create a solid foundation for the rest of your process and save you the headache of having to realise way too late, that you’re not solving the right problem. Because if your foundation is weak, the tower is going to fall no matter how well you build the rest of it.
Here’s an example to illustrate my point:
Mark has a dream of opening a food truck, and since Mark has a sweet tooth, he immediately thinks of ice cream as his product of choice. So he walks down the street and interviews a lot of people in the neighbourhood about their favourite ice cream flavours. He does a lot of research on where to import the highest quality ice cream at the lowest price and on what location gets the most traffic — everything points towards a great launch! When he opens the shop on the first day, Mark is surprised to find that he doesn’t sell a single ice cream.. But why?
If Mark had asked people about what food they were missing in the neighbourhood instead of assuming that everybody loves ice cream as much as he does, he would have discovered that people actually think the weather is too cold for ice cream, and that they’d rather have hot tacos since that part of town is both low on cheap lunch options and Mexican cuisine. The point is, that if you ask people what flavour ice cream they like, they’re not going to say tacos. If you let your assumptions narrow your perspective and close your mind off to alternatives, you’re never going to ask the right questions, and thus, you’ll never discover how to solve the right problems, regardless of how much research you do.
Now, you probably think that I hate assumptions, right?
Actually, I think they’re great, and they are basically the foundation of HDD. Assumptions only become a problem when you rely on them exclusively instead of using them as the starting point in your research.
Let’s walk through how you can do just that with HDD to help you get a great start on your new product/feature.
HDD is split into the following four phases; Assumptions, Hypotheses, Research and Design & build. Let’s dive in!
Assumptions
You probably already have an idea of what kind of problem you’re dealing with and how you’re going to approach it, right? That’s great! We want to gather as many assumptions as possible.
If it’s a new product or feature, start with the core problem. What is the primary need you’re trying to accommodate?
If it’s an improvement to an existing problem, you should start with potential solutions from existing knowledge. If existing data or information on the issue is available to you, build your assumptions on that. You will be one step ahead in articulating hypotheses that are relevant to test.
Here’s another example for you:
Lisa works in a big office building which has a small coffee shop on the ground floor. The shop is so busy that she regularly waits in line for over 15 minutes to get her coffee — but who has time for that? Lisa and her co-workers in the building are considering going to another shop because of the long wait, but the coffee is so good and cheap in the building’s shop that it would be a shame.
Lisa decides to see if something can be done. She wants to create a solution, so she sets up her first assumption:
- If the people working in the building didn’t have to wait in line for so long to get their coffee, they would be less likely to switch to another coffee shop.
Lisa’s assumption works because it’s broad. It’s partly based on an objective observation (people are tired of waiting in line) and partly based on data from customers, including herself (they’re considering switching coffee shop). She doesn’t assume what solution would work, and thus, she is not lead into a narrow and possibly wrong direction too early as the unfortunate Mark from our previous example was. Keep your assumptions relatively broad to reduce risk.
When working with assumptions, I recommend the following process:
- Plan sessions
You’ll want to plan some sessions with different groups of people. At Nodes, we sit down with the product manager, the developers and other relevant stakeholders from the company who are knowledgable on the subject. - Speak to users
You’ll also want to speak to existing or potential customers/users and ask them about the problem that needs solving, and what they imagine the solution being. This can be a little abstract for people who don’t work with products, but often the output can be very valuable! People who are not directly involved in product development or design can sometimes have creative ideas because they’re experiencing the problem first hand! - Write down assumptions
Write it all down in a document or put it on the wall on post-it’s. - Prioritise assumptions
Start prioritising your assumptions. Think about what might have the biggest impact on your users’ needs and prioritise accordingly. Limit the number of assumptions to what is realistic to test in the time frame that you’re operating under.
Hypotheses
After you’ve prioritised your assumptions it’s time to convert them into hypotheses. For a hypothesis to be scientific, it must be testable. The whole idea behind this phase is to convert your assumptions into something actionable that you can test and validate. To set up your hypothesis, you can use the following framework as a guide:
Let’s grab Lisa’s assumption about the coffee shop lines from earlier and put it into this framework:
Now, we’ve converted Lisa’s assumption into an actionable hypothesis that we can test later. If you have more than one assumption, you should convert the rest of them to hypotheses at this stage.
To structure your hypotheses, consider gathering them into a table to give you a clear overview. It will also come in handy while conducting user interviews, especially if you’re getting inputs on several hypotheses in one session. The table below is an example of how we structure hypotheses at Nodes:
Research
Once your hypotheses are set up, it’s time to test if they’re true or false. In the research phase, you collect empirical and measurable evidence that will allow you to determine whether or not you should design your product/feature based on your hypotheses.
There are a vast amount of ways to conduct your research, and you will need to determine which UX method is best to measure each hypothesis. Methods may vary from interviews and usability tests to data analysis and competitor analysis etc. If possible, try to use both a qualitative and a quantitative research method to test each hypothesis.
To exemplify with Lisa’s hypothesis from earlier, she could set up some user interviews (qualitative) with her colleagues at the office and maybe also a questionnaire (quantitative) for the whole building, to get a wider dataset. There are plenty of UX methods to choose from! Don’t be scared to try out new ones.
If you need inspiration for choosing the right UX methods for your context, I highly recommend UXkit. It’s very in-depth and will help you determine when to use which method.
When you’ve gathered your results for each hypothesis, fill out your table columns with either “True”/”Plausible”/“False” and add a note explaining your main findings.
Design & build
Now, you should have a pretty good idea of what your future users want and what they don’t want from validating your hypotheses. This is your new product/feature foundation. From here, it’s time to turn the hypotheses into user stories and set up your success criteria, so you can start the design process, test your first product prototype and get some feedback, before you start development. The product journey from here is an article for another time.
Takeaway
The Hypothesis-Driven Design process has been a huge help for me, and I’m certain that it has helped our team build better products.
Because this approach forces you to answer vital questions and collect knowledge in the early stages of the process, your perspective for designing a viable solution widens and becomes less limited by your own subjective beliefs.
When your approach is grounded in research and testing, “killing your darlings” becomes less painful, as your decisions are now based on objective findings and a true sense of what you’re actually trying to solve and how you should do it.
You’re creating a scientific foundation that your whole team can use as guideline to build from, and they can consult it throughout the process, if needed. This common ground may help you obtain better alignment of your team efforts.
Another great advantage about HDD is its scalability! I’ve used it for large research projects that lasted more than 3 months as well as smaller projects of 1–2 weeks. Every time, it has had a major impact on what we thought we where going to build versus what we actually ended up building.
Most importantly, I’ve experienced that the products and features we’ve build with this process have ended up being a way bigger success with customers and users.
HDD helps you reduce risk and build better products, while teaching you a lot about your users, your colleagues and how to conduct research in general.
