lean-ux — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited lean-ux (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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?"
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.
Goal: 10/10. Rate UX processes, design plans, or team workflows 0-10 against Lean UX principles: hypothesis-driven design, minimal deliverables, collaborative practices, and outcome-focused metrics score high; heavy-deliverable thinking or untested assumptions lower the score. Always state the current score and the specific improvements needed to reach 10/10.
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:
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 for the assumption prioritization matrix and hypothesis statement formats.
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:
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.
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:
Product applications:
| Context | Application | Example |
|---|---|---|
| Early concept validation | Paper prototype or clickable mockup | Sketch 3 concepts, test with 5 users same day |
| Demand validation | Landing page smoke test | "Sign up for early access" measures real interest |
| Usability validation | Clickable prototype test | Figma prototype tested with 5-8 users |
| Pricing validation | Painted door test | Show pricing page, measure click-through 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.
See: references/experiment-patterns.md for experiment types, selection guidance, and design templates.
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:
Product applications:
| Context | Application | Example |
|---|---|---|
| Sprint kick-off | Design Studio session (90 minutes) | Whole team sketches solutions to the sprint's hypothesis |
| Feature exploration | Collaborative sketching workshop | 6-up sketches: each person draws 6 ideas in 5 minutes |
| Remote teams | Virtual whiteboard sessions | FigJam or Miro board with timed sketch rounds |
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 for the Design Studio method and living style guides.
Core concept: Continuous, lightweight research replaces big-bang usability studies—small research activities embedded in every sprint instead of quarterly reports.
Why it works: Feedback that arrives months after a design decision is too late to influence it; cheap, frequent research lets teams correct course incrementally.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Weekly usability testing | Test prototype with 3-5 users every Thursday | "Testing Thursday" ritual with rotating facilitators |
| Post-launch learning | Monitor analytics + 3 follow-up interviews | Find drop-off points, interview churned users |
| Persona validation | Compare proto-persona assumptions to interview data | "We assumed power users are marketers; data shows ops managers" |
Ethical boundary: Conduct research with informed consent—participants should understand how their data is used and be free to withdraw.
Core concept: Lean UX works inside Agile via dual-track development: discovery (learning what to build) and delivery (building it) run in parallel.
Why it works: Design work doesn't fit neatly into a delivery sprint; running discovery one sprint ahead means validated designs are ready when the delivery sprint begins, instead of design forever catching up.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Sprint planning | Include hypothesis validation in sprint goals | "Sprint goal: validate that inline editing cuts task time 20%" |
| Backlog refinement | Attach experiment results to stories | Story moves to delivery only after hypothesis is validated |
| Retrospectives | Review learning velocity alongside delivery velocity | "We validated 4 hypotheses and invalidated 2 this sprint" |
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.
See: references/agile-integration.md for dual-track agile and staggered sprint mechanics.
| 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 |
| Documenting instead of collaborating | 40-page specs nobody reads | Replace specs with shared understanding from co-design |
| Measuring outputs not outcomes | Shipping features that don't change behavior | Define success as behavior change, not delivery |
Audit any UX process or design plan:
| 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 metrics per feature |
| Does UX work feed into Agile smoothly? | Design bottleneck or sprint-zero trap | Implement dual-track agile with staggered sprints |
| Can you point to a recently invalidated hypothesis? | Not learning; confirmation bias | Review the experiment log and celebrate a pivot |
For the complete methodology, research, and case studies:
Jeff Gothelf is an organizational designer, coach, and author who spent over 15 years leading UX teams at companies including TheLadders and Neo Innovation; watching teams waste months on unvalidated deliverables led him to create Lean UX. Josh Seiden is a designer and product strategist with 25+ years of experience who co-founded the interaction design practice at Cooper and was Managing Director at Neo Innovation. Together they co-authored Lean UX and Sense and Respond.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.