VOCABULARY / ENTRY
Lean UX
lean-ux
Treating design work as a series of hypotheses to be validated: the team first writes down the outcomes it wants and the assumptions behind them, runs an experiment with the least work possible to test the riskiest one, and then decides from the result whether to continue, adjust, or drop it. It borrows the build–measure–learn loop of the Lean Startup, and measures progress by what was learned rather than by how many documents were delivered.
Recognizing it
- Work is organised around hypothesis statements of the form "we believe … if …" rather than around feature lists
- The team first names the one thing it most needs to learn this round, then looks for the least work that will validate it
- Goals are written as observable changes in user behaviour, not as a number of screens to deliver
Concept boundary
Lean UX does not mean doing less design or skipping research: it reduces deliverables that do not help anyone learn, not the understanding of users. Nor is it agile development itself — it is a way of organising design and product discovery within an agile rhythm, and Gothelf's earliest article says it can also be used in a waterfall process. It differs from participatory design: Lean UX involves users as subjects of experiments and sources of feedback, while direction and tradeoffs are still decided by the product team on the evidence; participatory design requires the people affected to hold part of the decision power themselves. Users giving feedback in an experiment does not mean they took part in the decision.
When to consider it
- The direction is highly uncertain and getting it wrong costs more than running one more experiment
- The team can reach real users often and see results within short cycles
- Design, product, and engineering are willing to share judgement over outcomes rather than handing documents down a chain
When to be cautious
- Mistakes are irreversible or involve safety or compliance, so rough experiments on real users are not acceptable
- "Minimum viable" is used to justify shipping a low-quality product indefinitely
- Experiment metrics track only short-term clicks and ignore long-term effects that are hard to quantify
Tradeoff
Writing solutions as hypotheses and testing them early with small experiments catches a wrong direction before heavy development and lets the team argue about evidence rather than opinion; the cost is a reliance on signals that can be measured quickly, which leaves it insensitive to effects that are hard to quantify or slow to appear, and frequent small experiments themselves wear on users' patience and trust.
Conditional rules · Editorial advice
Related entries
Both bring users into the design process often, but in Lean UX users are subjects of experiments and sources of feedback while the team still decides on the evidence; in participatory design the people affected hold part of the decision power themselves.
Human-centred design provides the understanding of needs and contexts, and Lean UX turns that understanding into testable hypotheses and orders the experiments.
Lean UX suits stages where the direction is set and needs quick validation; while the problem itself is still unclear, the Double Diamond's emphasis on defining the problem fits better.
Experiments that count clicks or conversions as outcomes can quietly erode hard-to-quantify values such as privacy and autonomy; state in advance which values may not be traded away in an experiment.
Sources and what they support
In this article of 7 March 2011, Jeff Gothelf introduces Lean UX: it is inspired by Lean and Agile development theories and focuses on the experience rather than on documents; only the core flows are prototyped and put in front of users early, a validated prototype can serve as the specification, and heavy deliverables are treated as waste; collaboration with the whole team is critical to the product's success; and because it focuses on the design phase it can be used under either waterfall or Agile. This entry takes its points about reducing deliverables that do not help learning and about not being agile itself from it.
Retrieved: 2026-10-20 · Snapshot unconfirmedIn this article of 28 June 2021, Gothelf presents the Lean UX Canvas that he and Josh Seiden use in the book Lean UX: the team writes down the business problem, business outcomes expressed as changes in customer behaviour, users, user benefits, and possible solutions, combines them into "we believe …" hypothesis statements, identifies the riskiest point it most needs to learn first, and designs the least work needed to test it (such as interviews, prototypes, landing pages, or A/B tests). This entry takes its definition and the hypothesis statement, most-important-thing-to-learn, and least-work signatures from it.
Retrieved: 2026-10-20 · Snapshot unconfirmedThe page lists the principles of the Lean Startup: the build–measure–learn feedback loop of turning ideas into products, observing how customers respond, and deciding whether to pivot or persevere should be accelerated; a minimum viable product (MVP) starts the learning as early as possible; and the unit of progress is validated learning. This entry uses it only to describe the loop and the measure-progress-by-learning idea that Lean UX borrows; linking the two is this entry's editorial judgement.
Retrieved: 2026-10-20 · Snapshot unconfirmedDefinitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
This entry has no runnable specimen; the illustration is an editorial sketch using a loop to show hypothesis, experiment, and learning, and does not reproduce the canvas from any book. Before applying it to a team, write down the concrete hypotheses, experiment methods, and stopping conditions.
{
"values": [
"Progress is measured by what was learned, not by how much was delivered",
"A solution is only a hypothesis until it has been shown to work"
],
"tension": "Between the speed of fast learning and effects that are long-term and hard to quantify",
"questions": [
"What do we most need to learn this round?",
"What is the least work that will validate it?",
"Who bears the cost of this experiment?"
]
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.