“Let’s test a red button” is an idea. A hypothesis explains why the change should matter, for whom, and how you’ll know. That difference decides whether a test teaches you anything.
The template
Because we observed [evidence from research or analytics], we believe [specific change] for [audience or segment] will [increase/decrease] [primary metric], because [the mechanism: what changes in the user’s mind or effort]. We’ll know by [primary metric, guardrails, MDE and decision rule].
Download or fill in the hypothesis template.
Good and bad examples
Weak: “Changing the CTA colour will increase conversions.” No evidence, no audience, no mechanism. If it loses, you’ve learned nothing.
Strong: “Because 31 of 120 exit-survey answers mention unexpected delivery costs, and recordings show shoppers pausing at the shipping line, we believe showing the delivery cost and date on the product page for all UK visitors will increase checkout completion, because removing a late surprise reduces perceived risk. We’ll know by checkout completion rate (MDE 8% relative), with average order value and returns as guardrails.”
(Numbers in this example are illustrative.)
Checklist
0 of 7 done (saved in this browser only)
Why the mechanism matters
If the test loses, the mechanism tells you what to doubt. Was the evidence wrong (people don’t actually care about delivery cost)? Or was the execution weak (they didn’t notice the new line)? Each answer points to a different next test.
From hypothesis to roadmap
In the WXM Architect phase, every hypothesis is scored with PXL and the highest-scoring ones go to Validate.