Building a Hypothesis

A test idea is just a hunch. A hypothesis turns it into a testable prediction with a reason and an expected outcome.

"Let's try a new headline" is an idea. "A benefit-led headline will raise signups because visitors don't understand the value" is a hypothesis you can actually evaluate.

A strong hypothesis has three parts: the change, the expected effect, and the metric that proves it. A reusable sentence keeps everyone honest.

Fill in each bracket with something specific and measurable before you build the variant.

The best hypotheses include the reasoning behind the change. The "because" forces you to connect the test to real user behavior.

Extend the template: "We believe [change] will cause [effect] because [insight], measured by [metric]." This makes failed tests informative, not just disappointing.

Imagine survey data shows users distrust your pricing. You decide to add a guarantee.

The hypothesis writes itself when you follow the template. Notice how specific the change, effect, and metric all are.

Vague metrics like "engagement" or "better performance" cannot be measured cleanly. Pick one primary metric that maps directly to the change.

If the change is on the checkout page, the primary metric is usually checkout completion or purchase rate, not page views or time on site.

Track one primary metric to declare a winner, plus guardrail metrics to catch unintended harm.

If shrinking a form lifts signups but tanks lead quality downstream, your guardrail caught a false win. Define both before launch.

A testable hypothesis predicts a direction (up or down) and ideally a rough magnitude. "Conversion will improve" is weak; "conversion will rise by at least 10%" is sharp.

An expected effect size also helps you plan how much traffic the test will need.

Every hypothesis should cite a source: analytics, heatmaps, surveys, support tickets, or prior tests.

If you cannot point to evidence for why a change will work, the idea is a guess. Evidence-backed hypotheses win more often and teach you more when they lose.

A good hypothesis can be proven wrong. If no possible result would change your mind, it is an opinion, not a hypothesis.

Decide in advance what outcome would make you reject the change. This protects you from rationalizing a flat or negative result after the fact.

Write the full hypothesis, primary metric, guardrails, and expected effect before the test goes live. Lock it down so results cannot be reinterpreted later.

Pre-registration prevents cherry-picking and keeps your experimentation program credible.

Compare two versions of the same idea. The weak one is untestable; the strong one is specific, reasoned, and measurable.

Train your team to upgrade every weak hypothesis into the strong form before any work begins on the variant.

Which option is the strongest hypothesis?

Turn ideas into predictions with the template: we believe [change] will cause [effect] because [insight], measured by [metric].

Pick one specific primary metric plus guardrails, predict direction and size, ground it in evidence, keep it falsifiable, and document it before launch.