lean-ux

---
name: lean-ux
description: Use when applying lean, hypothesis-driven UX: assumption mapping, design hypotheses, MVPs for UX, collaborative sketching, or cutting heavy design documentation.
category: Design
version: 1.0.0
tools: []
---

# 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. 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, 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. State the current score, the failed rows, and the fix for each.

## Framework

### 1. Declaring Assumptions

Every design starts with assumptions. Lean UX makes them explicit so they can be prioritized and tested, rather than baked invisibly into specifications — unspoken assumptions mean teams build on shaky ground and discover problems only after launch. **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:** assumption mapping workshops at feature kick-off ("We assume users want to share reports with teammates"); rank roadmap features by assumption risk; 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 — acknowledge a constraint rather than pretending it's open to falsification.

### 2. Hypothesis Statements

A hypothesis translates an assumption into a testable prediction, linking a proposed change to a measurable outcome for a specific user segment. 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:** write a hypothesis before wireframing ("We believe trial-to-paid conversion will rise 10% if new users complete a guided setup wizard"); formalize A/B test rationale ("We believe click-through will rise 15% if we move the CTA above the fold"); attach a hypothesis to each sprint story.

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

### 3. MVPs and Experiments

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. 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:** paper prototype or clickable mockup for early concept validation (sketch 3 concepts, test with 5 users same day); landing page smoke test for demand validation; Figma prototype tested with 5-8 users for usability; painted-door pricing test before building billing.

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

### 4. Collaborative Design

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 — developers who helped sketch the solution don't need a 40-page spec to build it. **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." Style guides and pattern libraries are living documents; reduce deliverables to the minimum needed for shared understanding (often a whiteboard photo).

**Product applications:** a 90-minute Design Studio session at sprint kick-off; 6-up sketches (each person draws 6 ideas in 5 minutes) for feature exploration; virtual whiteboard sessions (FigJam, Miro) for remote teams.

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

### 5. Feedback and Research

Continuous, lightweight research replaces big-bang usability studies — small activities embedded in every sprint instead of quarterly reports, because findings only change a decision while it's still cheap to reverse. Research types: usability tests, customer interviews, A/B tests, analytics review, surveys, diary studies. Five users uncover approximately 85% of usability problems (Nielsen). Continuous cadence: recruit weekly, test weekly, synthesize weekly. The whole team should observe at least some sessions to build empathy. Proto-personas are refined and eventually replaced by evidence-based personas.

**Product applications:** "Testing Thursday" — test a prototype with 3-5 users every week with a rotating facilitator; monitor analytics plus 3 follow-up interviews post-launch; compare proto-persona assumptions to interview data.

**Ethical boundary:** conduct research with informed consent — participants should understand how their data is used and be free to withdraw.

### 6. Integration with Agile

Lean UX works inside Agile via **dual-track development**: discovery (learning what to build) and delivery (building it) run in parallel, staggered one sprint ahead so validated designs are ready when the delivery sprint begins. User stories gain a hypothesis and success metric alongside acceptance criteria. "Definition of Done" for UX includes validated learning, not just shipped pixels. Backlog items from invalidated hypotheses are removed, not deferred.

**Product applications:** sprint goals that include hypothesis validation ("Sprint goal: validate that inline editing cuts task time 20%"); attach experiment results to backlog stories before they move to delivery; review learning velocity alongside delivery velocity in retros.

**Ethical boundary:** never use Lean UX as an excuse to skip accessibility, security, or compliance — these are non-negotiable quality standards, not assumptions to test.

## Common Mistakes

| Mistake | Why It Fails | Fix |
|---------|-------------|------|
| **Treating MVPs as launches** | Over-building by conflating MVP with first release | Reframe: MVP = learning tool, not product launch |
| **Skipping assumption declaration** | Hidden assumptions become expensive surprises | Run a 30-minute assumption mapping session at kick-off |
| **Hypothesis without success criteria** | Can't tell if the experiment passed | Pre-commit to metric, threshold, and sample size |
| **Designer-only design** | Handoff waste, misalignment, slow iteration | Run Design Studio sessions with the full team |
| **Research as a phase** | Feedback arrives too late to matter | Embed lightweight research in every sprint |
| **Ignoring invalidated hypotheses** | Building features that failed testing | Remove invalidated items from the backlog; pivot or drop |
| **Measuring outputs not outcomes** | Shipping features that don't change behavior | Define success as behavior change, not delivery |

## Quick Diagnostic

| Question | If No | Action |
|----------|-------|--------|
| Are assumptions explicitly declared? | Hidden assumptions drive decisions | Run an assumption mapping workshop |
| Is there a testable hypothesis? | Building on opinion | Write hypothesis in standard format before designing |
| Is the experiment the lowest fidelity that answers the question? | Over-investing before learning | Downgrade to paper prototype or smoke test |
| Does the whole team participate in design? | Handoff waste and misalignment | Schedule a Design Studio session |
| Is research happening every sprint? | Feedback loop too slow | Establish a weekly testing cadence |
| Are you tracking outcomes, not just outputs? | Shipping without learning | Define behavior-change metric |