Hypothesis driven design
In the team I work in, we have adopted a formal way of doing "Hypothesis Driven Design".
Hypothesis driven design is where you design solutions and test them with your users. Advancing your understanding and business solution though each design.
Hypothesis driven design isn't new. It is having an idea and testing it.
Many designers work in a hypothesis driven way but don't write their ideas down. This implicit way of coming up with an idea and then testing it is less than ideal.
A hunch or a gut feel is a great start. But it isn't a repeatable, sharable method.
Hypothesis as the articulation of intent
Hypotheses can be big or small. They are statements that can cover things like changing the colour of a button. Or a wider user need or story.
A hypothesis is a statement. A statement of your current understanding and what change you expect to see. A hypothesis is an articulation of your intent.
A written hypothesis exists to communicate your thinking. As well as letting you and others test your thinking. To verify it.
If we expect a certain user outcome if we change our button, is this the best way to do that? If we expect a certain outcome, did that happen when we tested it?
A good hypothesis is testable and verifiable. It can be true or false. A written hypothesis lets others see, test and verify your thinking.
In the team I work in, we write our hypotheses using a formal language. We use:
- [Context]
- If [some action]
- Then [outcome for users]
- Because [reason for outcome]
The context let's us frame why we are trying to solve a particular problem. We found this made writing easier. It also made them easier to understand when we returned to them.
Your context could come from data. A hunch. A user lab. Other people. Or a mixture.
An example could be:
'In lab 5 users struggled to navigate between pages. No user used the native browser back button. The researcher had to intervene to return to the homepage".
The rest of the statement frames what we are going to do, what impact that'll have on the user and why.
One line suffices for each.
Writing these statements surfaces your reasoning behind your design decisions. It makes you a better designer. It acts as documentation. It helps you communicate the intent behind your design.
Where our statements live
We use a Kanban board to track our design work. We write our hypotheses as our design work matures.
We then attach the hypothesis statements as comments to our cards in Jira.
Before any design artefact is given to a developer or tested, it must have a hypothesis attached to it.
When we review our design work, we review the hypothesis.
The prototypes we build are a collection of hypotheses. Some proven, some not. When we test our prototype with users, we see if our expectations are true or not.
Sometimes our hypotheses miss the mark. This can be because our design wasn't clear enough in rendering our intent. Or because our intent doesn't match what our users want or need.
The benefits of using hypothesis driven design
Hypothesis driven design is a process that generates easy to understand documentation. A log of your design thinking and decisions.
Writing design hypotheses isn't always pleasurable. It can be tough to get them exactly right. But they make you a better designer.
The act of articulating your design choice further refines your design. And your skills as a designer.
By using a hypothesis driven design process you:
- Articulate your thinking
- Provide others with understanding of your thinking
- Create a framework to test your designs against
- Develop a standard way of documenting your work
- Make better stuff
I've been playing with the format.
My latest hypothesis statement format