Framing your work as a hypothesis means no longer just thinking about the thing you’re making or building, but paying more attention to whether that work is achieving your intended goals and outcomes.
When done collaboratively, hypothesis-building is powerful at getting a team on the same page about what it’s doing and why. It also allows the team to be flexible — if one approach doesn’t result in the outcome you expected, you have implicit permission to change course and try something else.
How to do it
- As a team, identify and make explicit the problem you’re trying to solve. What goals or needs aren’t being met? What measurable criteria would indicate progress toward those goals?
As a team, write out the hypothesis for the work you want to do to address the problem(s) you’re trying to solve. You may want to write broad hypotheses at the outset of a project and more specific hypotheses each sprint.
Here’s a common way to structure your hypothesis:
We believe that doing/building/creating [this] for [this user] will result in [this outcome].
We’ll know we’re right when we see [this metric/signal].
Once you’ve formulated your hypothesis, consider the following harm prompt to help the team think about and guard against potential unintended consequences of your work.
But, this could be harmful for [this user] if [this outcome happens].
- Identify a user touchpoint that will allow you to test your hypothesis, such as external marketing, the homepage, a microsite, or something else. Test your hypothesis. If you learn something unexpected, refine your hypothesis, test again, and continue to work incrementally towards your goals.
- Article from Smashing Magazine on using design hypotheses in Lean UX
Considerations for use in government
No PRA implications. No information is collected from members of the public.