Lean UX

Lean UX Framework

A practice-driven approach to UX that replaces heavy deliverables with rapid experimentation, cross-functional collaboration, and continuous learning. Lean UX shifts the question from "What should we design?" to "What do we need to learn?"

Core Principle

Outcomes over outputs. The value of a design is measured not by the fidelity of the deliverable but by the change in user behavior it produces.

The foundation: Traditional UX waterfalls requirements into wireframes, mockups, specs, and code—losing context and hiding untested assumptions at every handoff. Lean UX compresses the distance between idea and evidence: declare assumptions, form hypotheses, run the smallest possible experiment, and let real user behavior settle the argument. Shared understanding replaces documentation; learning velocity replaces pixel perfection.

Scoring

Goal: 10/10. Score a UX process, design plan, or team workflow by the eight-row Quick Diagnostic below: award ~1.25 points per row answered "yes" (8 yeses = 10). Bands:

• 9-10 — assumptions declared, hypotheses with pre-committed success criteria, lowest-fidelity experiments, whole-team design, weekly research, outcome (not output) metrics, dual-track agile, and a recently invalidated hypothesis on the books.
• 5-6 — hypotheses exist but criteria are vague or fidelity is over-invested; design and research still partly siloed.
• <=3 — heavy deliverables, untested assumptions, output-counting, no experiment log.

Always state the current score, the diagnostic rows that failed, and the specific fix for each.

Framework

1. Declaring Assumptions

Core concept: Every design starts with assumptions. Lean UX makes them explicit so they can be prioritized and tested, rather than baked invisibly into specifications.

Why it works: Unspoken assumptions mean teams build on shaky ground and discover problems only after launch; surfacing them early focuses energy on the riskiest ones and reduces the cost of being wrong.

Key insights:

• Business assumptions define what must be true for the business (revenue model, market size, willingness to pay); user assumptions define who users are and how they behave
• Prioritize on two axes: risk (how damaging if wrong) and uncertainty (how little we know)
• Test high-risk, high-uncertainty assumptions first
• Write assumptions collaboratively as a team, not in isolation

Product applications:

Ethical boundary: Assumptions must be honest assessments, not post-hoc justifications—if leadership has already committed to a direction, acknowledge the constraint rather than pretending it's open to falsification.

See references/hypothesis-canvas.md when running an assumption workshop or writing a hypothesis — the risk/uncertainty prioritization matrix, business-vs-user assumption split, and fillable hypothesis and sub-hypothesis templates.

2. Hypothesis Statements

Core concept: A hypothesis translates an assumption into a testable prediction, linking a proposed change to a measurable outcome for a specific user segment.

Why it works: Hypotheses force precision—instead of "make onboarding better," the team commits to a prediction that can be proven or disproven, which prevents scope creep and makes the learn step unambiguous.

Key insights:

• Standard format: "We believe [outcome] will happen if [persona] achieves [action] with [feature]"
• Every hypothesis specifies persona, action, outcome, and measurable signal
• Sub-hypotheses break a large bet into independently testable parts
• Agree on what "validated" and "invalidated" look like before running the experiment

Product applications:

Ethical boundary: Never cherry-pick metrics after the fact to declare a hypothesis validated—pre-commit to success criteria.

See references/outcome-metrics.md when picking the measurable signal for a hypothesis or defining team success — outcomes-vs-outputs, leading-vs-lagging indicator pairs, UX OKRs, and the vanity metrics to avoid.

3. MVPs and Experiments

Core concept: An MVP in Lean UX is the smallest design artifact that can test a hypothesis with real users—a learning tool, not a product launch.

Why it works: A paper prototype tested with five users in a hallway can invalidate a hypothesis that would otherwise consume a full engineering sprint; matching experiment fidelity to assumption risk maximizes learning per unit of effort.

Key insights:

• Experiments range from low fidelity (paper prototypes, concierge tests) to high fidelity (coded A/B tests, Wizard of Oz)
• Choose the lowest-fidelity experiment that can answer the question
• A good experiment has a clear hypothesis, defined audience, measurable signal, and time box
• Proto-personas can stand in for full research when speed matters, but must be validated later

Product applications:

Ethical boundary: Smoke tests and fake doors must not mislead users into believing a product exists—disclose test status and offer an opt-out.

See references/experiment-patterns.md when choosing or designing an experiment — the full catalog of experiment types with when/when-NOT-to-run notes, the experiment selection matrix and fidelity ladder, and a design template.

4. Collaborative Design

Core concept: Design is a team sport. Lean UX replaces the solitary designer-then-handoff model with cross-functional sessions where developers, PMs, and designers sketch solutions together.

Why it works: Developers who helped sketch the solution don't need a 40-page spec to build it—shared understanding replaces documentation, diverse perspectives generate more creative solutions, and handoff waste drops dramatically.

Key insights:

• Design Studio method: diverge (individual sketching), present, critique, converge (refined sketch), iterate
• The goal is informed commitment, not consensus: the team agrees on what to test, not what is "right"
• Cross-functional means engineers, QA, data analysts, and stakeholders sketch too
• Style guides and pattern libraries are living documents; reduce deliverables to the minimum needed for shared understanding (often a whiteboard photo)

Product applications:

Ethical boundary: Collaboration must not become design by committee—a designated designer synthesizes input; the team does not vote on pixels.

See references/collaborative-design.md when facilitating a Design Studio — the step-by-step workshop protocol (timings, materials, remote variants) and how to keep style guides as living documents.