A design hypothesis is a testable explanation of how a proposed change could affect a user’s behavior or experience. It connects a problem, a change, an expected effect, and the reason you expect that effect. It also identifies evidence that would make you reconsider the idea.
Write the hypothesis before polishing the solution. For example: “If the order review shows all charges before payment, shoppers will be able to explain the amount they are about to pay, because they no longer need to infer which charges are included.” You can build the relevant screens in Mockitt’s interactive prototype editor and investigate that comprehension question before development.
A practical design hypothesis template
Use this structure as a starting point: For [people in a situation], if we [change], then we expect [observable effect], because [reason grounded in evidence]. We would reconsider if [disconfirming observation]. The final sentence prevents the hypothesis from becoming a statement that every result can somehow support.
| Part | Checkout example | Why it matters |
|---|---|---|
| People and situation | Shoppers reviewing an order before payment. | Defines where the expectation applies. |
| Proposed change | Show the complete amount and a readable breakdown on the review screen. | Makes the design intervention specific. |
| Expected effect | People can identify the amount and explain whether delivery is included. | Describes something observable. |
| Reason | The existing design separates charges across screens. | Connects the change to a plausible mechanism that needs evidence. |
| Disconfirming observation | People still misunderstand the amount, or the new breakdown introduces another misunderstanding. | Leaves room to revise the explanation or design. |
This is a hypothetical example, not a claim about measured checkout performance. In a real project, replace the assumed problem with evidence from your own research. If you have not established that people misunderstand the amount, start by investigating that question.
Move from a finding to a hypothesis
Begin with a specific observation and keep it separate from your interpretation. “The participant returned to the basket twice” is an observation. “They did not trust the total” is an interpretation until you have supporting evidence. Returning might also reflect changing a quantity or checking an item.
Then identify the part of the design you believe contributes to the difficulty. Avoid making five changes at once if your immediate purpose is to learn which one matters. A new total, a new delivery selector, new payment options, and rewritten product descriptions may produce a better overall experience, but they make a narrow explanation harder to evaluate.
If several assumptions compete for attention, map the prototype’s assumptions first to decide what is important and uncertain. The hypothesis is the next step: it turns one selected uncertainty into a claim you can investigate.
Examples of weak and testable design hypotheses
| Weak statement | Better question or hypothesis |
|---|---|
| A simpler checkout will improve UX. | If required and optional fields are clearly distinguished, shoppers will identify what they must complete before continuing. |
| Users want an AI assistant. | Investigate which part of the task people cannot complete with the current information before selecting an assistant as the solution. |
| A larger button will increase conversion by 20%. | If the next action is visually distinct from secondary actions, people will recognize how to continue. A live conversion claim needs a separate measurement plan. |
| The new menu is intuitive. | When asked to change their delivery address, people will choose the intended route without being told which menu to open. |
Specific wording does not mean inventing a numerical target. Use a justified acceptance criterion when your team has a relevant baseline and a suitable study design. Do not attach an arbitrary percentage to make a statement sound scientific.
Choose evidence that can answer the claim
The method must fit what you are trying to learn. GOV.UK’s service standard connects understanding needs with testing assumptions and using prototypes. A prototype is useful when you need to explore a design before building it, but it cannot answer every business question.
- Comprehension or navigation: observe realistic tasks with a prototype and use neutral follow-up questions. Look at what people do and how they explain the result.
- Whether an idea addresses a valuable problem: investigate the problem and how people respond to the concept in its actual context. A usable interface is not evidence of demand.
- Operational feasibility: examine the required data, rules, dependencies, and team responsibilities. A clickable screen does not prove a backend process works.
- A change in real conversion or retention: use appropriate live measurement and, where suitable, a controlled experiment. Account for traffic, assignment, duration, and competing explanations.
A small qualitative study can uncover why someone misunderstands a flow. It does not establish a reliable population conversion lift. Conversely, a change in a dashboard metric may show that something happened without explaining why.
Build a focused prototype for the checkout example
Create the context people need: a basket, an order review, and the next step. Show consistent item prices, delivery information, and totals. Make the path back to the basket work, because returning is a plausible part of the task. Use synthetic order data and avoid collecting real payment details.
Mockitt lets you connect screens and preview interactions. Model the relevant choices and recovery paths rather than adding decorative transitions. The purpose of this prototype is to make the pricing information and next action understandable enough to investigate.
A neutral task might be: “You are considering this order for delivery next week. Review it and continue as far as you would before entering payment details.” Avoid asking someone to “find the clearly displayed total,” which reveals what you want them to notice.
Record whether the participant can explain the amount, which information they seek, where they return, and what they believe will happen next. Ask follow-ups after observing the relevant behavior where practical. Prompting too early can turn a comprehension problem into an assisted success.
Interpret the result without forcing a win
Separate observation, interpretation, and next action in your notes. If someone identifies the total but thinks delivery will be added later, the important issue is not merely whether they found the number. The explanation of what is included may still be unclear.
Decide whether to keep the change, revise it, investigate another cause, or stop pursuing the idea. An unexpected result can be useful even when it weakens the original hypothesis. Keep the original statement beside the evidence so the team can see how its understanding changed.
A research plan can document the participants, tasks, evidence, and decision this round is intended to inform. Once the question changes from understanding the prototype to measuring real behavior at scale, write a new hypothesis and choose a method capable of answering it.