Types of hypothesis
Difference between an assumption and hypothesis
The word hypothesis gets thrown around a lot at work, so I decided to do a short demonstration to understand the differences between an assumption and a hypothesis.
In a bag I put a mop slipper and I asked the team to put their hand in the bag, feel what it is but not to peak inside the bag.
What’s inside the bag? Some answers being a cleaning mop or a slipper or fuzzy toy.
I explained our opinions of what we think it is are assumptions.
How can we test to see what the actual object is?
I explained, when we turn an assumption into something that we can test with, then that is an hypothesis.
IF we take the object out of the bag
THEN we know if what the object is — if its a slipper or a mop
How I write hypothesis
I’m used to writing hypothesis in a certain way — using the format:
IF [action]
THEN [outcome]
BECAUSE [customer problem + feelings]
I use this for a higher overarching level of the project — (Let’s call this big branch), as well as smaller specific hypothesis for user testing (let’s call this twig/small branch).
(Big branch) hypothesis
For example, the big branch hypothesis when I’m designing the solution would be:
IF [we re-designed the loan flow by adding information on how the loan works and to highlight the main value props]
THEN [users will understand that the loan is different from a traditional loan and understands the benefits our loan and more likely to continue through the flow]
BECAUSE [ users won’t be confused by how it works and alleviate the feeling of disconnece with a traditional loan and that our ‘loan is dodgy’]
(Twigs/smaller branches) hypothesis
A smaller and specific hypothesis that would branch off from the big branch hypothesis for usability testing would look something like:
Breaking the ‘If’ in the success criteria column, the ‘then’ in the hypothesis column and I generally don’t write the ‘because’ section as it gets too wordy.
CCD way of writing hypothesis
Then my UX manager starting me on this book on Customer Driven design, and it was interesting how they write hypothesis in a different format for each stage:
I work within the last two stages (concept and feature), but I like how it’s quite specific to the information uncovered in each stage.
It also seems like it’s on a big branch level - but to write small branch hypothesis would be really wordy using this format.
Different ways of writing hypothesis
I asked my manager about the different styles of writing hypothesis — and I’m sure there are many more out there. He said:
“As long as all the main core ingredients are the same, doesn’t really matter in what way it is arranged.”
What I will use…
I like this format though for big branch hypothesis in the different stages over the IF/THEN/BECAUSE format — I feel like it creates a laser focus on what’s needed in each stage and builds on top of it.
Kind of like a plate of salad, with the salad leaves on the bottom first — like identifying customer in the first phase, then the protein on top, then dressing…etc
But I’ll keep the IF/THEN/BECAUSE format for any specific twiggy small branch type hypothesis as I’m used to it — its shorter, snappier and quicker.
But the most important message about hypothesis…
When collecting assumptions from product owners, pms, ux researchers, designers, developers…sometimes people can become attached and precious about their assumptions and feel like ‘winning’ if it scored the most to justify they were correct. This insight from the CCD book is really helpful as a reminder that any outcome is valuable:
“When you begin to test your assumptions with your customers, it’s easy to fall into a false belief that, to “win,” your assumptions must be proven right. This is an improper mindset for working and testing hypotheses. In fact:
An invalidated hypothesis is just as valuable as a validated one.”
The validated outcome ‘may’ be successful
Also if one outcome ‘won’, it might not necessarily mean its the best way, it’s the less riskiest option, with continual improvement (from the CCD book):
“Note that when a hypothesis has been validated or invalidated, it doesn’t become fact. You should think of hypotheses as an instrument to reduce risk. If you talk with 20 customers who all validate that your hypothesis is true, then you should feel as though you have greater confidence that it is.
Therefore, you must continually test your hypotheses to “de-risk” your product strategy. By validating or invalidating what you know to be true, you grow your understanding of what may be successful and what may not be.”
