Lean UX: principles, process and the think-make-check cycle

Lean UX is a way of designing digital products that replaces heavy documentation with fast experiments and shared learning. Teams state assumptions as hypotheses, build the smallest thing that tests them and use customer evidence to decide what to do next.

Jeff Gothelf and Josh Seiden set out the approach in their book Lean UX, first published in 2013. This guide covers the definition, principles, the think-make-check cycle, hypothesis statements, the Lean UX canvas and how it fits with agile sprints.

Key takeaways

Lean UX, or lean user experience design, focuses on learning from users quickly rather than producing detailed deliverables.

The core loop is think, make, check: form a hypothesis, build a small test and review the evidence.

Hypothesis statements turn design opinions into things you can test.

Design is a team activity shared with developers, product managers and others.

Lean UX fits inside agile sprints by treating each sprint as a chance to run a design experiment.

What is lean UX design?

Lean UX design is the application of lean startup thinking and agile working to user experience design. It prioritizes outcomes for users and the business over polished design documents.

Gothelf and Seiden wrote that the aim is to reduce waste by focusing on the experience being designed, not on deliverables. Their book draws on the lean startup method popularized by Eric Ries and on agile practice.

People also search for 'lean user experience' or 'lean UX methodology'. These phrases describe the same approach.

What are the principles of lean UX?

Lean UX rests on a few principles. These are cross-functional teams, small self-organized groups, a focus on outcomes over outputs and learning through experiments. Gothelf and Seiden describe a longer list in the book.

Cross-functional means designers, developers, product owners and others work on the problem together. Everyone shares what they learn.

Outcome focus means judging work by what changes for users, not by how many screens you produced. A finished wireframe is an output. A user completing a task more easily is an outcome.

Permission to fail is also part of the mindset. A failed test is useful information, as long as the team learns from it.

Agile UX vs lean UX

How does the think-make-check cycle work?

The think-make-check cycle is a loop in which you form a hypothesis, build a quick test of it and check the results with users. You then repeat with what you learned.

The cycle works like this:

1. Think: state the assumption and what outcome you expect.

2. Make: build the smallest artifact that can test it, such as a sketch, a clickable mock-up or a simple page.

3. Check: show it to users or measure behavior, then decide whether to continue, change or stop.

This mirrors the build, measure, learn loop of lean startup. Shorter loops mean you spend less time on ideas that do not work.

Small checks find a lot. Jakob Nielsen of the Nielsen Norman Group found that a first usability test with five users finds about 85% of the usability problems, and recommends many small tests over one large study.

Frame the problem before the solution

Teams often start with a feature because features feel concrete. Lean UX starts with the problem: who is affected, what they are trying to do, what gets in the way and why it matters.

Here is an illustrative case. 'Add an onboarding checklist' is a solution. 'New account owners are unsure which setup tasks they must finish before inviting teammates, so activation is delayed' is a problem frame. It leaves room for several solutions, and a checklist may or may not be the best one.

Five kinds of assumption to name

How do you write a lean UX hypothesis statement?

A lean UX hypothesis states what you believe, who it affects and how you will know it is true. A common form is: we believe that doing this for these people will achieve this outcome.

Add the evidence you will use: we will know we are right when we see a measurable change.

Here is an illustrative example. We believe that adding a progress bar to the sign-up form for new customers will reduce abandoned sign-ups. We will know we are right when more people finish the form.

A good hypothesis names a user, a change and a signal. If you cannot say what would prove it wrong, rewrite it.

A worked experiment with numbers

These numbers are illustrative. Today, 1,000 people a week start the sign-up form and 520 finish it, a completion rate of 52%.

Before the test, the team writes the pass line: the progress bar stays if completion reaches at least 57%, a gain of 5 points. Anything smaller is treated as noise for a test of this size.

They show the new form to half of the visitors for two weeks. The control version finishes 1,040 of 2,000 starts (52%). The progress bar version finishes 1,140 of 2,000 (57%). The result meets the pass line, so the change ships.

If the result had been 54%, the team would not argue its way to success. They would record the finding, ask users where they stop, and write the next hypothesis about that step instead.

What is the lean UX canvas?

The Lean UX canvas is a one-page tool created by Jeff Gothelf that frames a problem and guides a team from assumptions to experiments. It is a facilitation aid for a team session.

It moves through the business problem, the intended business outcomes, the users and their benefits, the proposed solutions, the hypotheses and the riskiest assumptions. Teams then choose experiments to test.

It plays a similar role to the Lean Canvas for startups. It is aimed at product and design teams working on a specific problem inside a larger business.

How do you run MVPs and experiments for UX?

In lean UX, you run the smallest test that can answer your question. This might be a paper sketch, a prototype, a landing page or a small live change.

The idea matches the minimum viable product concept. For a new feature, the MVP could be a manual process behind a simple screen. You then learn whether users want it before you build the real thing.

When you have enough traffic, you can compare two designs with live users. The A/B testing tools category describes software for this. For interviews and feedback, see the customer discovery tools category.

Keep experiments small and time-boxed. Say you test a new button label with a few hundred visitors over a week. The result guides the next step, not a final verdict.

Expect most live tests to disappoint. In Harvard Business Review, Ron Kohavi and Stefan Thomke report that only about 10% to 20% of experiments at Google and Bing generate positive results.

Match the experiment to the risk

How does lean UX fit with agile sprints?

Lean UX fits agile sprints by running design and discovery work alongside development rather than ahead of it. Designers and developers work together in the same cycle.

Instead of finishing all design before coding, the team designs just enough for the next sprint and tests as it builds. Findings feed into later sprints.

This is close to lean software development, which also treats learning as central. The lean agile software hub gathers related tools.

Before, during and after the sprint

A one-week lean UX cycle

An illustrative week for a small product team testing one hypothesis.

Monday: the whole team writes or picks the hypothesis and agrees the pass line. Tuesday: the designer and a developer sketch options together and choose one to build.

Wednesday: the team builds the smallest test, such as a clickable mock-up or a feature behind a switch. Thursday: five users try it in short sessions, or the live test starts.

Friday: the team reviews what it saw against the pass line and decides to continue, change or stop. The outcome becomes the input for next Monday.

Starting lean UX on one project: eight steps

What are common lean UX mistakes?

Is lean UX working? A ten-point check

Frequently asked questions