{ "_description": "Generated from data/ — edit the sources, not this file. The agent access guide explains the evidence boundary of every field.", "schemaVersion": "1.0.0", "kind": "entry", "locale": "en", "id": "lean-ux", "name": { "zh": "精益 UX", "en": "Lean UX" }, "page": "https://designvocabulary.com/en/entries/lean-ux/", "self": "https://designvocabulary.com/en/entries/lean-ux.json", "alternates": { "zh-CN": "https://designvocabulary.com/zh/entries/lean-ux.json", "en": "https://designvocabulary.com/en/entries/lean-ux.json" }, "site": { "catalogSchemaVersion": "0.1.0", "entries": 158, "index": "https://designvocabulary.com/en/entries/index.json", "query": "https://designvocabulary.com/api/query?lang=en", "guide": "https://designvocabulary.com/en/agents/", "llms": "https://designvocabulary.com/llms.txt" }, "provenance": { "sourceBacked": [ "entry.definition" ], "editorial": [ "entry.boundary", "entry.signature", "entry.when", "entry.when_not", "entry.tradeoff", "entry.comparison", "entry.rules", "entry.relations", "entry.implementationNote", "entry.philosophy" ], "scope": "Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.", "editorialStatus": "drafted", "specimenData": "fictional", "specimenNote": "Original fictional specimens. Definitions cite sources; usage advice and recipes are editorial.", "sources": [ { "id": "leanux-gothelf-2011", "url": "https://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/", "title": "Smashing Magazine · Lean UX: Getting Out Of The Deliverables Business (Jeff Gothelf)", "checkedAt": "2026-10-20", "archive": { "status": "unconfirmed", "confirmed": false, "url": null, "capturedAt": null, "lookupUrl": "https://web.archive.org/web/20261020*/https://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/" } }, { "id": "leanux-canvas", "url": "https://jeffgothelf.com/blog/how-to-use-the-lean-ux-canvas/", "title": "Jeff Gothelf · How to use the Lean UX Canvas", "checkedAt": "2026-10-20", "archive": { "status": "unconfirmed", "confirmed": false, "url": null, "capturedAt": null, "lookupUrl": "https://web.archive.org/web/20261020*/https://jeffgothelf.com/blog/how-to-use-the-lean-ux-canvas/" } }, { "id": "leanux-leanstartup-principles", "url": "https://theleanstartup.com/principles", "title": "The Lean Startup · Principles", "checkedAt": "2026-10-20", "archive": { "status": "unconfirmed", "confirmed": false, "url": null, "capturedAt": null, "lookupUrl": "https://web.archive.org/web/20261020*/https://theleanstartup.com/principles" } } ], "lists": [], "ordered": false, "listDisclaimer": "Seat numbers are editorial positions, not scores, rankings, or popularity measurements. A list that is not filled is left as it is." }, "entry": { "id": "lean-ux", "type": "philosophy", "name": { "zh": "精益 UX", "en": "Lean UX" }, "aliases": [ "Lean User Experience", "Lean UX Canvas", "精益用户体验", "精益设计" ], "granularity": "experience", "intents": [ "understand-users", "assess-impact", "reduce-complexity" ], "tags": [ "hypotheses", "experiments", "minimum viable product", "outcome-driven", "fast learning" ], "definition": "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.", "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.", "signature": [ "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" ], "when": [ "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_not": [ "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.", "comparison": { "focus": "Validating the hypotheses behind a solution as early as possible, measuring progress by learning rather than delivery", "mechanism": "Writing down outcomes and hypotheses, testing the riskiest with the least work, and iterating on the result", "cost": "It favours quickly measurable signals, so long-term and hard-to-quantify effects are easily missed" }, "sources": [ { "id": "leanux-gothelf-2011", "title": "Smashing Magazine · Lean UX: Getting Out Of The Deliverables Business (Jeff Gothelf)", "url": "https://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/", "claim": "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.", "checkedAt": "2026-10-20", "archive": { "lookupUrl": "https://web.archive.org/web/20261020*/https://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/", "status": "unconfirmed", "checkedAt": "2026-10-20T08:00:13.662Z", "error": "save-request-failed" } }, { "id": "leanux-canvas", "title": "Jeff Gothelf · How to use the Lean UX Canvas", "url": "https://jeffgothelf.com/blog/how-to-use-the-lean-ux-canvas/", "claim": "In 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.", "checkedAt": "2026-10-20", "archive": { "lookupUrl": "https://web.archive.org/web/20261020*/https://jeffgothelf.com/blog/how-to-use-the-lean-ux-canvas/", "status": "unconfirmed", "checkedAt": "2026-10-20T08:00:15.760Z", "error": "save-request-failed" } }, { "id": "leanux-leanstartup-principles", "title": "The Lean Startup · Principles", "url": "https://theleanstartup.com/principles", "claim": "The 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.", "checkedAt": "2026-10-20", "archive": { "lookupUrl": "https://web.archive.org/web/20261020*/https://theleanstartup.com/principles", "status": "unconfirmed", "checkedAt": "2026-10-20T08:00:16.460Z", "error": "save-request-failed" } } ], "relations": [ { "target": "participatory-design", "kind": "related", "condition": "The role users play in the process needs to be told apart", "reason": "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.", "basis": "editorial" }, { "target": "human-centered-design", "kind": "composes_with", "condition": "Deciding which assumption about users to validate first", "reason": "Human-centred design provides the understanding of needs and contexts, and Lean UX turns that understanding into testable hypotheses and orders the experiments.", "basis": "editorial" }, { "target": "double-diamond", "kind": "related", "condition": "Choosing how to organise design work", "reason": "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.", "basis": "editorial" }, { "target": "value-sensitive-design", "kind": "conflicts_when", "condition": "Experiments measure only short-term behavioural metrics", "reason": "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.", "basis": "editorial" } ], "rules": [ { "when": "Running experiments with real users", "instruction": "Set the experiment's stopping conditions and the lines that may not be traded (such as privacy, safety, and features already promised) in advance, and do not test irreversible or safety-related decisions with rough experiments.", "strength": "must", "basis": "editorial" }, { "when": "A minimum viable experiment returns a positive result", "instruction": "Replace the experimental version with an implementation that meets normal quality standards and record what this round taught, rather than letting the experiment become the long-term deliverable.", "strength": "recommend", "basis": "editorial" } ], "philosophy": { "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?" ] }, "demo": null, "version": "0.1.0", "editorialStatus": "drafted", "requirements": [], "demoCapabilities": [], "implementationNote": "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.", "image": { "src": "/images/lean-ux.webp", "alt": "A sketch: three nodes form a clockwise loop — a card of grey bars representing a hypothesis, a rough fictional FIELDNOTES prototype interface, and a results panel showing a simple change in bars — linked in turn by arrows, with a small light bulb at the centre of the loop standing for what was learned." }, "searchTerms": [ "假设", "实验", "最小可行产品", "成果导向", "快速学习" ] } }