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:**

| Context | Application | Example |
|---------|-------------|---------|
| **New feature kick-off** | Assumption mapping workshop | "We assume users want to share reports with teammates" |
| **Roadmap planning** | Rank features by assumption risk | Prioritize features whose success depends on untested beliefs |
| **Stakeholder alignment** | Expose hidden assumptions across roles | PM assumes pricing works; engineer assumes scale; designer assumes flow |

**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](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:**

| Context | Application | Example |
|---------|-------------|---------|
| **Feature design** | Write hypothesis before wireframing | "We believe trial-to-paid conversion will rise 10% if new users complete a guided setup wizard" |
| **A/B tests** | Formalize test rationale | "We believe click-through will rise 15% if we move the CTA above the fold" |
| **Sprint planning** | Attach hypothesis to each story | Story: "filter by date." Hypothesis: "task completion time drops 30%" |

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

See [references/outcome-metrics.md](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:**

| Context | Application | Example |
|---------|-------------|---------|
| **Early conce