Written by: Monstarlab
Releasing new products and features is often risky business. If you do not solve the right problem or meet your users’ expectations, it can have detrimental consequences to your company’s success.
From experience, I have learned that new releases are most risky when they are built on an equally unreliable foundation — assumptions.
We tend to think that we know what people want and need, but sadly, I have learned that assumptions do not work like a God-given sixth sense or a guiding light of clarity. In fact, we are more often wrong than we are 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 is a scientific approach to help you understand the problem you are 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 are 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 is 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 does not 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 would 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 are not going to say tacos. If you let your assumptions narrow your perspective and close your mind off to alternatives, you are never going to ask the right questions, and thus, you will 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 are 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 us 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 are dealing with and how you are going to approach it, right? That’s great! We want to gather as many assumptions as possible.
If it is a new product or feature, start with the core problem. What is the primary need you are trying to accommodate?
If it is 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 is 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 did not 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 is broad. It is partly based on an objective observation (people are tired of waiting in line) and partly based on data from customers, including herself (they are considering switching coffee shops). She does not assume what solution would work, and thus, she is not led 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.
TIP: Using post-its can be a great way to get an overview of your assumptions.
When working with assumptions, I recommend the following process:
- Plan sessions
You will want to plan some sessions with different groups of people. At Monstarlab, we sit down with the product manager, the developers and other relevant stakeholders from the company who are knowledgeable on the subject. - Speak to users
You will 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 do not 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 are experiencing the problem first hand! - Write down assumptions
Write it all down in a document or put it on the wall on post-its. - 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 are operating under.
Hypothesis
After you have prioritised your assumptions, it is 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:
Consider Lisa’s assumption about the coffee shop lines from earlier and put it into this framework:
Now, we have 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 are getting inputs on several hypotheses in one session. The table below is an example of how we structure hypotheses at Monstarlab:
Research
Once your hypotheses are set up, it is time to test if they are 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! Do not 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 is very in-depth and will help you determine when to use which method.
When you have 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 do not want from validating your hypotheses. This is your new product/feature foundation. From here, it is 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.
Key Takeaways
- The Hypothesis-Driven Design process has been a huge help for me, and I am 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 are actually trying to solve and how you should do it.
- You are creating a scientific foundation that your whole team can use as a 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 have 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 were going to build versus what we actually ended up building.
- Most importantly, I have experienced that the products and features we have built 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.