npx skills add https://github.com/wondelai/skills --skill lean-ux一种实践驱动的用户体验设计方法,以快速实验、跨职能协作和持续学习取代繁重的交付物。基于一个基本事实:那些在与真实用户测试之前执着于像素级完美规格的团队,会浪费数月时间构建错误的东西。Lean UX 将问题从“我们应该设计什么?”转变为“我们需要学习什么?”
成果重于产出。 设计的价值不是由交付物的保真度来衡量,而是由它产生的用户行为改变来衡量。
基础: 传统的用户体验瀑布式流程将需求转化为线框图,线框图转化为模型,模型转化为规格,规格转化为代码。在每一次交接中,上下文都会丢失,假设都未经测试。Lean UX 通过压缩想法与证据之间的距离来消除浪费。团队不再在会议室里争论意见,而是声明假设、形成假设、运行尽可能小的实验,并让真实的用户行为来解决问题。共享理解取代了文档。学习速度取代了像素级完美。
目标:10/10。 在评审或创建 UX 流程、设计计划或团队工作流时,根据其对 Lean UX 原则的遵循程度进行 0-10 分评分。10/10 表示完全符合假设驱动设计、最小化交付物、协作实践和以成果为中心的指标;较低的分数表示存在繁重交付物思维或未经测试的假设。始终提供当前分数以及达到 10/10 所需的具体改进措施。
核心理念: 每个设计都始于假设。Lean UX 使这些假设变得明确,以便可以对其进行优先级排序和测试,而不是无形地融入规格中。
为何有效: 当假设未被言明时,团队在摇摇欲坠的基础上构建,直到发布后才发现问题。通过尽早揭示假设,团队可以首先将精力集中在风险最高的假设上,从而降低犯错的成本。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 新功能启动 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 假设映射工作坊 |
| “我们假设用户希望与队友分享报告” |
| 重新设计计划 | 识别你对当前用户的信念 | “我们假设用户离开是因为仪表盘令人困惑” |
| 路线图规划 | 按假设风险对功能排序 | 优先处理那些成功依赖于未经测试信念的功能 |
| 利益相关者对齐 | 揭示跨角色的隐藏假设 | 产品经理假设定价有效;工程师假设可扩展性有效;设计师假设流程有效 |
伦理边界: 假设应该是诚实的评估,而不是为已做出的决策进行事后合理化。如果领导层已经承诺了某个方向,应承认这一约束,而不是假装假设可以被证伪。
核心理念: 假设将假设转化为可测试的预测。Lean UX 假设格式将提议的变更与特定用户群体的可衡量结果联系起来。
为何有效: 假设迫使精确性。团队不再说“让入门流程更好”,而是承诺一个可以被证明或证伪的具体预测。这防止了范围蔓延,明确了成功标准,并使学习步骤清晰无误。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 功能设计 | 在线框图之前撰写假设 | “我们相信如果新用户完成引导设置向导,试用转付费转化率将提高 10%” |
| A/B 测试 | 形式化测试理由 | “我们相信如果将 CTA 移到首屏,点击率将上升 15%” |
| 冲刺计划 | 为每个用户故事附加假设 | 故事:“作为用户,我可以按日期筛选。” 假设:“我们相信任务完成时间将下降 30%” |
| 回顾会议 | 评审已验证与已证伪的假设 | “本季度 5 个假设中有 3 个已验证;2 个已调整方向” |
伦理边界: 切勿事后挑选指标来宣布假设已验证。预先承诺成功标准。
核心理念: Lean UX 中的 MVP 是能够用真实用户测试假设的最小设计产物。它不是产品发布;它是一个学习工具。
为何有效: 繁重的交付物会延迟学习。在走廊里用五个用户测试的纸质原型,可以证伪一个原本会消耗整个冲刺工程量的假设。通过将实验保真度与假设风险相匹配,团队可以更快地学习,浪费更少。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 早期概念验证 | 纸质原型或可点击模型 | 当天绘制 3 个概念,与 5 个用户测试 |
| 需求验证 | 着陆页烟雾测试 | “注册获取早期访问权限”衡量真实兴趣 |
| 可用性验证 | 可点击原型测试 | 用 5-8 个用户测试 Figma 原型 |
| 技术可行性 | 绿野仙踪法 | 手动后端,自动化前端以测试体验 |
| 定价验证 | 画门测试 | 展示定价页面,在构建计费功能前衡量点击率 |
伦理边界: 烟雾测试和假门测试不得误导用户相信产品存在而实际不存在。始终披露测试状态并提供退出方式。
核心理念: 设计是一项团队运动。Lean UX 取代了孤立的设计师然后交接的模式,采用跨职能设计会议,让开发人员、产品经理和设计师一起构思解决方案。
为何有效: 当整个团队都参与设计时,共享理解取代了文档。帮助构思解决方案的开发人员不需要 40 页的规格说明来构建它。多样化的视角能产生更具创意的解决方案。交接浪费显著减少。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 冲刺启动 | 设计工作室会议(90 分钟) | 整个团队为冲刺的假设构思解决方案 |
| 功能探索 | 协作构思工作坊 | 6-up 构思:每个人在 5 分钟内绘制 6 个想法 |
| 设计系统维护 | 活的风格指南更新 | 工程师和设计师在构建时一起更新指南 |
| 远程团队 | 虚拟白板会议 | 使用 FigJam 或 Miro 板进行限时构思轮次 |
伦理边界: 协作不得变成委员会设计。指定的设计师综合输入;团队不对像素进行投票。
核心理念: 持续、轻量级的研究取代了大型可用性研究。Lean UX 将研究嵌入到每个冲刺中,使团队能够不断从真实用户行为中学习,而不是按季度进行。
为何有效: 在设计决策做出数月后才收到的反馈,已经太晚而无法影响它。通过在每次冲刺中运行小型研究活动,团队可以逐步纠正方向。每个研究活动的成本很低,因此团队可以负担得起频繁测试。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 每周可用性测试 | 每周四用 3-5 个用户测试原型 | “测试星期四”仪式,轮换主持人 |
| 发布后学习 | 监控分析 + 进行 3 次后续访谈 | 识别流失点,访谈流失的用户 |
| 人物角色验证 | 将原型人物角色假设与访谈数据进行比较 | “我们假设高级用户是营销人员;数据显示他们是运营经理” |
| 竞争性研究 | 每季度进行轻量级竞争分析拆解 | 团队评审 3 个竞争对手 30 分钟,捕捉模式 |
伦理边界: 用户研究必须在知情同意的情况下进行。参与者应了解其数据将如何使用,并有权退出。
核心理念: Lean UX 设计用于在敏捷开发内部工作。双轨敏捷将发现(学习构建什么)与交付(构建它)分开,并行运行这两个轨道。
为何有效: 传统 UX 在敏捷中挣扎,因为设计工作无法整齐地融入冲刺。双轨制通过让发现轨道比交付轨道提前一个冲刺运行来解决这个问题。发现轨道产生已验证的假设和经过测试的原型;交付轨道将它们转化为可发布的软件。
关键见解:
产品应用:
| 上下文 | 应用 | 示例 |
|---|---|---|
| 冲刺计划 | 将假设验证纳入冲刺目标 | “冲刺目标:验证内联编辑是否将任务时间减少 20%” |
| 待办事项细化 | 将实验结果附加到故事上 | 只有在假设被验证后,故事才转移到交付轨道 |
| 回顾会议 | 评审学习速度与交付速度 | “本冲刺我们验证了 4 个假设,证伪了 2 个” |
| 路线图更新 | 根据实验结果调整路线图 | 已证伪的功能从 Q3 路线图中移除 |
伦理边界: 不要以 Lean UX 为借口跳过可访问性、安全性或合规性工作。这些是不可协商的质量标准,而不是需要测试的假设。
| 错误 | 为何失败 | 修复方法 |
|---|---|---|
| 将 MVP 视为发布 | 团队过度构建,因为他们混淆了“最小可行产品”和“首次发布” | 重新定义:MVP = 学习工具,而非产品发布 |
| 跳过假设声明 | 隐藏的假设变成昂贵的意外 | 在启动时进行 30 分钟的假设映射会议 |
| 没有成功标准的假设 | 无法确定实验是通过还是失败 | 预先承诺指标、阈值和样本量 |
| 仅设计师参与设计 | 交接浪费、错位、迭代缓慢 | 与完整的跨职能团队一起运行设计工作室会议 |
| 研究作为一个阶段 | 反馈来得太晚,无法影响决策 | 将轻量级研究嵌入到每个冲刺中 |
| 忽略已证伪的假设 | 团队构建了测试失败的功能 | 从待办事项中移除已证伪的项目;调整方向或放弃 |
| 记录而非协作 | 40 页没人读的规格说明 | 用协作会议产生的共享理解取代规格说明 |
| 衡量产出而非成果 | 发布不改变行为的功能 | 将成功定义为行为改变,而不是功能交付 |
审核任何 UX 流程或设计计划:
| 问题 | 如果否 | 行动 |
|---|---|---|
| 假设是否明确声明? | 隐藏的假设驱动决策 | 运行假设映射工作坊 |
| 是否有可测试的假设? | 团队基于意见构建 | 在设计前以标准格式撰写假设 |
| 实验是否是能回答问题的最低保真度? | 在学习前过度投资 | 降级为纸质原型或烟雾测试 |
| 整个团队是否参与设计? | 交接浪费和错位 | 安排设计工作室会议 |
| 每个冲刺是否都有研究? | 反馈循环太慢 | 建立每周测试节奏 |
| 是否跟踪成果,而不仅仅是产出? | 发布而没有学习 | 为每个功能定义行为改变指标 |
| UX 工作是否顺利融入敏捷? | 设计瓶颈或冲刺零陷阱 | 实施错开冲刺的双轨敏捷 |
| 能否指出最近证伪的一个假设? | 团队没有学习;确认偏误 | 评审实验日志并庆祝一次方向调整 |
此技能基于 Jeff Gothelf 和 Josh Seiden 开发的 Lean UX 原则。关于完整的方法论、研究和案例研究:
Jeff Gothelf 是一位组织设计师、教练和作家,帮助公司构建更好的产品并培养以成果为中心的文化。他在代理机构和产品公司担任 UX 设计师和团队领导超过 15 年,包括 TheLadders、Publicis Modem 和 Neo Innovation(现为 Pivotal Labs)。他目睹团队在未经验证的交付物上浪费数月时间的经历,促使他开发了 Lean UX,作为设计思维、敏捷开发和精益创业原则的实用融合。Gothelf 为财富 500 强公司提供教练服务,并在国际上就产品管理、组织敏捷性和基于证据的设计发表演讲。
Josh Seiden 是一位设计师、产品战略家和教练,拥有超过 25 年的经验,帮助团队构建数字产品。他共同创立了 Cooper 的交互设计实践,这是最早的 UX 咨询公司之一,后来担任 Neo Innovation 的董事总经理。Seiden 专注于帮助组织从产出驱动的工作方式转变为成果驱动的工作方式。他与 Gothelf 合著了《Lean UX》和《Sense and Respond》,这两本书已成为采用敏捷和精益实践的产品团队的必读之作。
每周安装量
214
代码库
GitHub 星标数
255
首次出现
2026年2月23日
安全审计
安装于
codex206
opencode205
gemini-cli204
github-copilot204
cursor204
kimi-cli203
A practice-driven approach to user experience design that replaces heavy deliverables with rapid experimentation, cross-functional collaboration, and continuous learning. Based on a fundamental truth: teams that obsess over pixel-perfect specs before testing with real users waste months building the wrong thing. 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 not measured by the fidelity of the deliverable but by the change in user behavior it produces.
The foundation: Traditional UX waterfalls requirements into wireframes, wireframes into mockups, mockups into specs, and specs into code. At every handoff, context is lost and assumptions go untested. Lean UX eliminates waste by compressing the distance between idea and evidence. Instead of debating opinions in conference rooms, teams 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. When reviewing or creating UX processes, design plans, or team workflows, rate them 0-10 based on adherence to Lean UX principles. A 10/10 means full alignment with hypothesis-driven design, minimal deliverables, collaborative practices, and outcome-focused metrics; lower scores indicate heavy-deliverable thinking or untested assumptions. Always provide the current score and specific improvements needed to reach 10/10.
Core concept: Every design starts with assumptions. Lean UX makes those assumptions explicit so they can be prioritized and tested, rather than baked invisibly into specifications.
Why it works: When assumptions remain unspoken, teams build on shaky ground and discover problems only after launch. By surfacing assumptions early, the team can focus energy on the riskiest ones first, reducing 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" |
| Redesign initiative | Identify what you believe about current users | "We assume users leave because the dashboard is confusing" |
| 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 works; designer assumes flow works |
Ethical boundary: Assumptions should be honest assessments, not post-hoc justifications for decisions already made. If leadership has already committed to a direction, acknowledge that constraint rather than pretending the assumption is open to falsification.
See: references/hypothesis-canvas.md
Core concept: A hypothesis translates an assumption into a testable prediction. The Lean UX hypothesis format links 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 specific prediction that can be proven or disproven. This prevents scope creep, sharpens success criteria, 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 increase by 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 user story | Story: "As a user I can filter by date." Hypothesis: "We believe task completion time drops 30%" |
| Retrospectives | Review validated vs. invalidated hypotheses | "3 of 5 hypotheses validated this quarter; 2 pivoted" |
Ethical boundary: Never cherry-pick metrics after the fact to declare a hypothesis validated. Pre-commit to success criteria.
See: references/hypothesis-canvas.md
Core concept: An MVP in Lean UX is the smallest design artifact that can test a hypothesis with real users. It is not a product launch; it is a learning tool.
Why it works: Heavy deliverables delay learning. A paper prototype tested with five users in a hallway can invalidate a hypothesis that would otherwise consume a full sprint of engineering. By matching experiment fidelity to the risk of the assumption, teams learn faster and waste less.
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 |
| Technical feasibility | Wizard of Oz | Manual backend, automated frontend to test experience |
| Pricing validation | Painted door test | Show pricing page, measure click-through before building billing |
Ethical boundary: Smoke tests and fake door tests must not mislead users into believing a product exists when it does not. Always disclose the test status and offer a way to opt out.
See: references/experiment-patterns.md
Core concept: Design is a team sport. Lean UX replaces the solitary designer-then-handoff model with cross-functional design sessions where developers, product managers, and designers sketch solutions together.
Why it works: When the whole team participates in design, shared understanding replaces documentation. Developers who helped sketch the solution do not need a 40-page spec to build it. Diverse perspectives generate more creative solutions. 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 |
| Design system maintenance | Living style guide updates | Engineers and designers update the guide together as they build |
| 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
Core concept: Continuous, lightweight research replaces big-bang usability studies. Lean UX embeds research into every sprint so teams learn from real user behavior constantly rather than quarterly.
Why it works: Feedback that arrives months after a design decision is too late to influence it. By running small research activities every sprint, teams correct course incrementally. The cost of each research activity is low, so the team can afford to test frequently.
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 + run 3 follow-up interviews | Identify drop-off points, interview users who churned |
| Persona validation | Compare proto-persona assumptions to interview data | "We assumed power users are marketers; data shows they are ops managers" |
| Competitive research | Lightweight competitive teardown each quarter | Team reviews 3 competitors for 30 minutes, captures patterns |
Ethical boundary: User research must be conducted with informed consent. Participants should understand how their data will be used and have the right to withdraw.
See: references/experiment-patterns.md
Core concept: Lean UX is designed to work inside Agile development. Dual-track agile separates discovery (learning what to build) from delivery (building it), running both tracks in parallel.
Why it works: Traditional UX struggles in Agile because design work does not fit neatly into a sprint. Dual-track solves this by running discovery one sprint ahead of delivery. The discovery track generates validated hypotheses and tested prototypes; the delivery track turns them into shippable software.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Sprint planning | Include hypothesis validation in sprint goals | "Sprint goal: validate that inline editing reduces task time by 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" |
| Roadmap updates | Adjust roadmap based on experiment outcomes | Invalidated feature removed from Q3 roadmap |
Ethical boundary: Do not use Lean UX as an excuse to skip accessibility, security, or compliance work. These are non-negotiable quality standards, not assumptions to be tested.
See: references/agile-integration.md
| Mistake | Why It Fails | Fix |
|---|---|---|
| Treating MVPs as launches | Team over-builds because they conflate "minimum viable product" 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 | Cannot determine if experiment passed or failed | Pre-commit to metric, threshold, and sample size |
| Designer-only design | Handoff waste, misalignment, slow iteration | Run Design Studio sessions with the full cross-functional team |
| Research as a phase | Feedback arrives too late to influence decisions | Embed lightweight research into every sprint |
| Ignoring invalidated hypotheses | Team builds features that failed testing | Remove invalidated items from backlog; pivot or drop |
Audit any UX process or design plan:
| Question | If No | Action |
|---|---|---|
| Are assumptions explicitly declared? | Hidden assumptions drive decisions | Run assumption mapping workshop |
| Is there a testable hypothesis? | Team is building on opinion | Write hypothesis in standard format before designing |
| Is the experiment the lowest fidelity that can answer 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 is too slow | Establish weekly testing cadence |
| Are you tracking outcomes, not just outputs? | Shipping without learning | Define behavior-change metrics for each 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 hypothesis you invalidated recently? |
This skill is based on Lean UX principles developed by Jeff Gothelf and Josh Seiden. For the complete methodology, research, and case studies:
Jeff Gothelf is an organizational designer, coach, and author who helps companies build better products and cultivate outcome-focused cultures. He spent over 15 years as a UX designer and team leader at agencies and product companies, including TheLadders, Publicis Modem, and Neo Innovation (now Pivotal Labs). His experience watching teams waste months on unvalidated deliverables led him to develop Lean UX as a practical fusion of design thinking, Agile development, and lean startup principles. Gothelf coaches Fortune 500 companies and speaks internationally on product management, organizational agility, and evidence-based design.
Josh Seiden is a designer, product strategist, and coach with over 25 years of experience helping teams build digital products. He co-founded the interaction design practice at Cooper, one of the first UX consultancies, and later served as Managing Director at Neo Innovation. Seiden specializes in helping organizations shift from output-driven to outcome-driven ways of working. Together with Gothelf, he co-authored Lean UX and Sense and Respond , both of which have become essential reading for product teams adopting Agile and Lean practices.
Weekly Installs
214
Repository
GitHub Stars
255
First Seen
Feb 23, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex206
opencode205
gemini-cli204
github-copilot204
cursor204
kimi-cli203
推荐与联盟计划设计优化指南:病毒式增长营销策略、客户推荐计划、联盟营销
27,600 周安装
| 40-page specs nobody reads |
| Replace specs with shared understanding from collaborative sessions |
| Measuring outputs not outcomes | Shipping features that do not change behavior | Define success as behavior change, not feature delivery |
| Team is not learning; confirmation bias |
| Review experiment log and celebrate a pivot |