Lean UX Canvas: The Problem and the Hypothesis on One Page

What is it, and where does it come from?

The Lean UX Canvas comes from the Lean UX practice. Jeff Gothelf, who wrote the book Lean UX with Josh Seiden, explains the canvas as a working order and says the book is organized around it. The core idea is to treat each feature as a hypothesis: an assumption about what users need and what business outcome will follow. If the assumption is false, it is better to find out early and cheaply.

IxDF describes it as a one-page framework for aligning teams around assumptions, hypotheses, and experiments, covering business goals, user segments, assumptions, hypotheses, and success metrics. The point is not to fill it in, but to use it to decide what to test next.

What are its eight boxes?

Gothelf presents the canvas as a working order. These are the eight boxes, in the order he suggests filling them in:

1. Business problem: the problem the organization has, without mentioning solutions.
2. Business outcomes or behaviors: which measurable behaviors should change.
3. Users: a proto-persona with needs, obstacles, and context.
4. User outcomes and benefits: what the person gains if the problem is solved.
5. Solutions: possible ideas, not yet prioritized.
6. Hypothesis: the statement that connects boxes 2 to 5.
7. Most important thing to learn first: the biggest risk in the hypothesis.
8. Least work to learn it: the least work needed to learn the next most important thing. The answers are experiments.

Box 6 is the one that organizes the rest. If you cannot write it in one sentence, you do not yet know what you are testing.

How do you write a hypothesis you can test?

Gothelf proposes this form: we believe this business outcome will be achieved if this user attains this benefit with this feature. It has three parts that can be checked separately: the business outcome, the user, and the feature.

Other sources use a different wording, for example, “we believe this solution will achieve this outcome for this user because these reasons”. The difference is not substantive, but consistency matters: choose one form and use it across the team so hypotheses can be compared.

A good hypothesis is one that could turn out wrong. If no test could disprove it, it cannot teach you anything.

How do you prioritize what to test?

Gothelf handles prioritization on a separate canvas, the Hypothesis Prioritization Canvas. To choose where to start, he suggests a matrix of risk against perceived value:

• High risk and high value: test first. This is what can change the outcome most.
• High value and low risk: no test needed; Gothelf says to just build, ship, and measure.
• Low value: generally not tested and probably not built, however attractive the idea feels. High-risk, low-value ideas are usually thrown away.

On the matrix, the risk axis depends on context (design, marketing, brand) and the value axis is the expected impact on customers and the business. It is a conversation tool, not a calculation: it forces the team to justify why an idea sits at the top.

What happens after each experiment?

Gothelf describes a simple cycle. If the hypothesis holds, boxes 7 and 8 are repeated with the next most important risk and progressively higher-fidelity experiments, which confirm the signal with something more costly. If it does not hold, the team can pivot or discard it, and it reviews the whole canvas, because the error may be in the problem, the user, or the solution.

This last part is the one most often forgotten. A failed experiment is not a failure if it changes how the team understands the problem.

When should you NOT use the Lean UX Canvas?

• When the business problem is already validated and there is no uncertainty to test. The canvas adds work without learning.
• When the team cannot run experiments or has no access to users. A canvas without tests stays at the level of assumptions.
• To justify decisions already made. Using it as a formality turns the boxes into an approval document.

Example

Illustrative example: an expense tracking app for freelancers has high abandonment in the first month.

• Business problem: many users stop using the app before connecting their bank account.
• User: a freelancer who invoices little each month and does not want to review every expense by hand.
• Hypothesis: we believe monthly retention will rise if the freelancer sees an expense summary in under five minutes, because they will not have to categorize every transaction.
• Most important thing to learn: whether the freelancer trusts automatic categorization.
• Least work to learn it: a test with five people who categorize by hand, then see the automatic proposal, with nothing built.

If the test fails, the team learns that the problem was not load time but trust. That changes the next hypothesis.

To move from hypothesis to flow design, the user flows artifact is usually the next step, and prototypes can test the hypothesis without building it fully. If your case has a clear user profile, personas help complete box 3.

Common mistakes

• Skipping user research and filling the users box with guesses.
• Treating hypotheses as facts instead of questions to answer.
• Building before validating the riskiest hypothesis.
• Reading “lean” as a synonym for low effort or low quality.
• Measuring whether users use the solution, but not whether it achieves the business outcome.
• Filling in all eight boxes in one session and never returning to them.

Sources

• Jeff Gothelf, How to use the Lean UX Canvas
• IxDF, Lean UX