Everything is hypothesis driven design
I think that everything can be seen as hypothesis driven design. The real question is whether or not we write down the assumptions behind the design decisions we make and measure outcomes.
Why hypothesis driven design
The book I recommend for understanding hypothesis driven design is Lean UX by Jeff Gothelf.
“Each design is a proposed business solution – a hypothesis. Your goal is to validate the proposed solution as efficiently as possible by using customer feedback”
Hypothesis driven design helps teams take calculated risks to move a product forward and explore different solutions. This is all about taking bigger and better steps towards meeting user needs. It’s a way of making sure that you’re being iterative with proposed design solutions – remember, making incremental changes to prototypes isn’t iterative.
The point I want to make is that this isn’t hard. The important thing is write things down. The hard part is being brave and designing good experiments.
Knowing why we’re doing something
It’s important to agree why we’re doing something.
Good agile teams produce lots of prototypes and design iterations in the early stages of product development. It’s important that these teams understand each iteration. We need to know why we’ve taken each of the different design approaches. Which insights from user research have led us to approach the problem in a new or different way?
Writing something down is about having the conversation. It forces you to get to a shared understanding of what we’re doing and why.
Making all design decisions hypothesis driven
Start by articulating what you’re thinking when designing something. For example:
Because I think [this] is true I think that doing [this] will mean [that this will happen].
Then talk through why you’re making design decisions with your team to get to a shared understanding. For example:
Because we think [this] is true we think that doing [this] will mean [that this will happen].
It’s important to get to this shared understanding. If we all have different assumptions about a design approach it can mean that we’re not agreed on what outcome the design is supposed to deliver.
If we don’t have a shared understanding of outcomes it’s difficult to measure if a solution works any better for users.
Measure, measure, measure
If you take the example from Lean UX you can then extend your hypothesis to include how you plan to measure what happens. For example:
Because we think [this] is true we think that doing [this] will mean [that this will happen]. We’ll know that this is true/false when we see this [key performance indicator change].
When working with a live service it’s especially important to put this emphasis on measurement. Making sure the design changes we make deliver the outcomes we think they will using performance data. We use tools like experiment boards to track and make this more visible in delivery teams.
As as footnote, I’ve been trying to think of a better names for hypotheses. I think ‘hypothesis’ makes it sound harder and more scientific than it is to use them. I even did a straw poll on Twitter. We couldn’t agree a better name, but here are some suggestions.
This is my blog where I’ve been writing for 18 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky, less frequently now on X (formally Twitter), and on LinkedIn.