Lars Damgaard
strategic user experience designer
June 28th 2017

Getting started with hypothesis driven design and why you should

The assumptions held by everyone involved in a product development process are dangerous for one simple reason: they might be wrong.

Hello Group experience designers on a hypothesis driven design project

Whether it’s a digital product, architecture, urban planning, social innovation or classical product development, projects run the risk of failing because they rest on false assumptions that are not questioned before the actual implementation.

At which point the ultimate and expensive test of assumption comes into play: do people want to use or buy your product, live in your building or to use your urban space.

Which is not what you want. What you want is to have valid knowledge about your assumptions as early enough for you to pivot and change direction based on the learnings and insights the team acquire throughout the process.

This article is also posted at Hello Group medium channel so if you’d rather read it on medium, feel free.

How we work with hypothesis driven design at Hello Group

In order to do so you need to bring the assumptions that stakeholders have to the front and and turn them into testable hypotheses.

In the list below I’ve tried to summarise how we work with hypothesis driven design at Hello Group, which is an eclectic mix of Google design sprints combined with the methodology described in the Lean UX book and The Innovator’s Hypothesis. The approach can be used regardless of the nature of your project.

If you have multiple ideas or concepts, you can apply any of the steps below to each of them. The aim is not to present a scientific framework, but to provide some useful and practical steps to get you started with a more experimental in a design processes.

Step 1: verbalise the assumptions that your idea is based on

As humans we constantly make assumptions. They are mental shortcuts that allow us to reduce and handle complexity. Quite a few of these assumptions are tacit, but a good way of kicking off a hypothesis driven design process is to do a session with post-it exercise (sorry, can’t help it) where the team defines an answer to the question “what needs to be true if this is going to fly”. In some cases these will be simple answers, but in many cases this is a pretty difficult exercise, but extremely important because it informs the rest of the experiment.

Step 2: define the most critical hypothesis that can be validly tested with the least amount of effort

Your answers to this exercise are mini hypotheses in themselves, but what you should do now is to rank them according to criticality; criticality here referring to the core assumption that needs to be true if your project is going to succeed that you’re most unsure about. Some things are trivial or known about due to prior research and might not be worthy of testing even though they might be critical.

As a designer you might know about best practice design patterns, but what you know less about is the context they’ll be put to play in and that’s what you need to investigate and understand in order to experiment with your design. In other words: make sure that you’re testing the right thing.
Hypothesis driven design is not usability testing of design patterns; it’s about being profoundly curious about the quality of you core idea.

Step 3: make a plan for how to test your hypothesis and create an artefact that allows for testing

At Hello Group we turn those assumptions into testable hypotheses by using this simple template:

The team believes that ___________
will likely result in ___________
and we will know this because ____________

Based on the nature of your hypothesis, you will need artefacts that allows for testing. Your artefact needs a fidelity level that allows people to react to it in a realistic way, which could mean anything from an elevator pitch, a landingpage, a pretotype, an interactive prototype or a physical prototype or model as long as it lets you do valid tests early on without investing too much time to construct the artefact.

Furthermore you need a plan for how to gather the insights needed to answer your hypothesis. Some hypotheses call for very quantitative measurements that can be answered in very direct ways whereas other hypotheses require qualitative insights or a combination of both.

Step 4: discard or adjust your idea

After testing your hypothesis you’ll need to analyse your findings and consider how to move forward. You will know if you feel confident enough to proceed or if you need to change direction completely. If the tests raise questions about the critical assumptions you defined in step 1, you might have a good case for adjusting your concept.
The gap between your project intention and the reality is so valuable: the questions that arise from it are more valuable than the data themselves, because it let’s you know where to focus your effort.

Experiment more with your design and your core idea!

A hypothesis driven approach can be used on any kind of project and allows a design or product team to be more experimental in the solution space for any given problem and to gather crucial knowledge early on.

Following the steps above also puts some structure on the process of exploring possible design solutions to a given problem — rather than just exploring aimlessly.

Thanks for reading. If you want to, feel free to follow me on twitter.