---
title: "Design hypothesis"
source: 18F Guides
source_url: https://github.com/18F/guides
licence: CC0-1.0
domain: engineering
subdomain: 18f-guides
date_added: 2026-04-25
---

## How to do it{#how-design-hypo}

1. 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?

1. 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.
    <p>
      Here’s a common way to structure your hypothesis:
    </p>
    <p>
      We believe that doing/building/creating [this] for [this user] will result in [this outcome].
    </p>
    <p>
      We’ll know we’re right when we see [this metric/signal].
    </p>

1. 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.

    <p>
      But, this could be harmful for [this user] if [this outcome happens].
    </p>

1. 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.

<section class="method--section method--section--government-considerations" markdown="1" >

## Government considerations{#con-design-hypo}

No PRA implications. No information is collected from members of the public.
</section>
