关于 lean-ux-canvas
面向产品经理的 Lean UX Canvas 技能，帮助团队围绕业务问题、用户、结果和假设开展协作，并设计验证假设的实验。适用于在投入开发前明确需要学习和测试的内容。
主要功能
- 01按 Lean UX Canvas v2 的八个区块引导
- 02明确业务问题与可衡量结果
- 03梳理用户、收益和解决方案假设
- 04找出首要学习内容与最小实验
- 05围绕跨职能协作组织讨论
适用场景
- 01启动产品计划或功能探索
- 02将已有项目重新聚焦于问题
- 03对齐团队的假设与实验
- 04规划 Discovery 冲刺或 MVP
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/lean-ux-canvas确认已加载。
附带文件examples/sample.mdtemplate.md
详细介绍
目的
引导产品经理创建 Jeff Gothelf 的 Lean UX Canvas（v2）——这是一种单页引导工具，围绕待解决的业务问题而非待实现的解决方案来规划工作。使用它可以让跨职能团队围绕核心假设达成一致，制定可测试的假设，并确保每个迭代都能通过揭示理解上的差距（问题、用户、价值，以及解决方案为何有效）来促进学习。
这不是路线图或功能列表，而是一份**“保险单”，能在投入完整开发之前将假设转化为实验。画布会将对话从产出转向成果**，确保团队做对的事，而不只是把事情做对。
输入
最适合的输入： 你正在界定的业务问题，或者别人交给你的解决方案构想——画布会将其重新界定为一个问题。 同样有用： 已知用户、目前已有的证据，以及团队已有的看法（需要梳理出的假设）。
随调用一并提供的任何内容——技能名称后的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已给出的答案。使用这些内容，并跳过其中已经涵盖的问题；不要重复询问。
两手空空也没关系。 该技能会从方框 1 开始：你想解决什么业务问题？
调用示例： Fill a Lean UX canvas: leadership wants 'an AI chatbot' — underlying problem seems to be support ticket volume growing 3x faster than the team.
核心概念
什么是 Lean UX Canvas？
Lean UX Canvas（v2） 是一种结构化的单页模板，旨在帮助团队围绕业务问题而非解决方案来规划工作。它让跨职能团队在以下方面达成一致：
- 存在什么问题（以及它为何当下很重要）
- 哪些可衡量的结果代表成功
- 我们要为哪些人解决问题
- 我们有哪些假设
- 我们需要先了解什么
- 哪些实验可以检验这些假设
起源： 由 Lean UX（O'Reilly，2013 年）作者 Jeff Gothelf 创建。版本 2 的发布旨在更清晰地区分业务成果与用户成果。
关键见解： 画布就像一份保险单——它能在构建之前揭示理解上的差距，确保你不会把迭代浪费在错误的事情上。
画布结构（8 个方框）
布局（3 列 × 3 行）：
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │ │ 2. Business Outcomes │
│ │ │ │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users │ (tall box │ 4. User Outcomes │
│ │ spanning │ & Benefits │
├─────────────────────┤ rows 1-2) ├───────────────────────┤
│ 6. Hypotheses │──────────────┤ 8. Least Work / │
│ │ 7. Learn │ Experiments │
│ │ First │ │
└─────────────────────┴──────────────┴───────────────────────┘
8 个方框（按以下顺序填写）：
- 业务问题 — 世界发生了什么变化，从而产生了一个值得解决的问题？
- 业务成果 — 哪种可衡量的行为变化代表成功？
- 用户 — 应该优先关注哪些用户画像？
- 用户成果与收益 — 用户为什么会寻求这一方案？他们能获得什么收益？
- 解决方案 — 哪些功能/计划可能解决问题并满足用户需求？
- 假设 — 结合方框 2–5 的可测试假设（采用 If/Then 格式）
- 最重要的待了解事项是什么？ — 当前风险最高的单一假设
- 接下来了解情况所需的最少工作是什么？ — 用于验证或证伪该假设的最小实验
为什么有效
问题优先，而非解决方案优先： 从“世界发生了什么变化？”开始，而不是“我们应该构建 X”。这样可以避免以解决方案为导向的思维。
以假设为驱动： 在开始构建之前明确提出假设。每个专业领域都能揭示自身的风险（技术可行性、用户价值、业务可行性）。
以实验为重点： 在投入资源之前检验假设。小型实验胜过重大押注。
跨职能协同： 共享画布能建立共同语言。每个人都能看到相同的理解差距。
关键区别（避免混淆）
框 2（业务成果）与框 4（用户成果）：
- 框 2： 可衡量的行为变化（留存率、网站停留时间、平均订单价值）
- 框 4： 目标、收益、情感、共情（省钱、获得晋升、与家人共度时光）
框 2 是指标。框 4 关乎人。
解决方案（框 5）是待验证的假设，而非承诺： 列出备选解决方案（功能、政策，甚至商业模式转变）。你不必承诺全部构建，而是在探索解决方案空间。
假设（框 6）是可测试的： 使用以下模板：“我们相信，如果[用户]通过[解决方案]获得[收益]，就能实现[业务成果]。”每个假设都聚焦于一个解决方案。
反模式（这不是什么）
- 不是功能清单： 解决方案是待测试的想法，不是待办事项
- 不是项目计划： 画布用于梳理学习，而不是制定交付时间表
- 不是策略的替代品： 画布用于执行策略，而非制定策略
- 不是一次性练习： 随着了解加深重新审视，并更新假设
何时使用
✅ 适用于以下情况：
- 启动新的产品计划或功能
- 重新审视现有项目（怀疑正在构建错误的东西）
- 让跨职能团队就假设和实验达成一致
- 规划探索冲刺或 MVP
- 利益相关者只关注解决方案（“我们需要构建 X”），而你需要揭示其中的假设
❌ 不适用于以下情况：
- 问题和解决方案都已验证（转入执行阶段）
- 战术性错误修复或技术债务（无需学习）
- 利益相关者不论证据如何都已决定采用某个解决方案（先解决共识问题）
引导流程的权威依据
将 workshop-facilitation 作为此技能的默认交互协议。
它定义了：
- 会话前提示和进入模式（引导式、上下文倾倒、最佳猜测）
- 每轮一个问题，并使用通俗易懂的提示
- 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
- 中断处理以及暂停和恢复行为
- 决策点上的编号建议
- 常规问题的编号快速选择选项（适用时包含
Other (specify)）
此文件定义了特定领域的评估内容。如有冲突，请遵循此文件的领域逻辑。
应用
使用 template.md 查看完整的填写结构。
此交互式技能会按顺序带你完成8 个自适应问题（每个问题对应画布中的一个框）。每一步，Agent 都会提供指导、示例和选项，帮助你正确填写该框。
步骤 0：收集上下文
Agent 提问：
在填写 Lean UX Canvas 之前，我们先收集一些背景信息。请分享：
业务背景：
- 利益相关者的请求、产品简介或计划描述
- 业务指标（收入、流失率、增长目标、KPI）
- 战略目标（OKR、路线图优先级）
用户背景：
- 客户研究、用户画像、JTBD 洞察
- 用户反馈、支持工单、流失原因
- 竞争对手分析、市场趋势
你可以粘贴：
- PRD 或产品简介
- 利益相关者备忘录
- 用户研究摘要
- 也可以简单描述一下这项计划
问题 1：业务问题（框 1）
Agent 提问：
你要解决的业务问题是什么？
请描述：
- 当前状态： 业务目前如何创造价值？
- 发生了什么变化： 市场变化、竞争威胁、客户行为变化或新的交付渠道
- 为什么重要： 为什么当前情况无法满足预期？
好的示例：
- “移动端流量超过桌面端后，我们的结账转化率下降了 15%。我们的结账流程并非为移动端设计，而竞争对手提供了一键结账。”
- “企业客户在 6 个月后流失，因为我们的入门流程需要 3 周以上的手动配置。竞争对手提供自助入门服务。”
不好的示例（太模糊）：
- “我们需要增加收入”（没有说明发生了什么变化）
- “用户想要更多功能”（没有说明业务问题）
Agent 提供 3 个选项：
- 我来描述业务问题 — [粘贴或编写你的描述]
- 帮我找出业务问题 — [Agent 提出后续问题：发生了什么变化？哪些指标受到影响？竞争对手在做什么？]
- 我不确定业务问题是什么 — [Agent 建议先从
skills/problem-statement/SKILL.md或skills/problem-framing-canvas/SKILL.md开始]
用户回复： [选择或描述]
Agent 验证： 这是否说明了发生了什么变化以及为什么这会造成问题？如果没有，请提出澄清问题。
问题 2：业务成果（框 2）
Agent 提问：
你如何判断自己解决了业务问题？要衡量什么？
重点关注可衡量的行为变化（也可以采用先行指标）。问问自己：“如果解决方案奏效，人们会有哪些不同的行为？”
业务成果示例：
- 将移动端结账转化率从 45% 提高到 60%
- 将企业客户入门时间从 3 周缩短到 3 天
- 将平均订单金额从 $50 提高到 $75
- 将客户支持工单减少 30%
- 将免费用户转付费用户的转化率从 5% 提高到 10%
重要提示： 这里是框 2（行为变化），而不是框 4（用户收益／共情）。指标写在这里，情绪写在框 4。
Agent 提供 3 个选项：
- 我已经想好了具体指标 — [说明你的业务成果]
- 帮我定义可衡量的成果 — [Agent 根据业务问题建议指标]
- 我只有滞后指标（收入、利润） — [Agent 帮助找出能够预测这些成果的先行指标]
用户回复： [选择或描述]
Agent 验证： 这些成果可衡量吗？可观察吗？它们能体现行为变化吗（而不只是“增加收入”）？
问题 3：用户（框 3）
Agent 提问：
你应该优先关注哪些类型（即用户画像）的用户和客户？
请考虑：
- 谁购买产品？
- 谁使用产品？
- 谁配置产品？
- 谁管理产品？
为什么重要： 团队往往会在这里走捷径（“所有人”）。画布希望建立对用户的共同愿景，而这个用户不总是“客户”。
示例：
- “专业服务行业中拥有 1 至 10 名员工的中小型企业主（顾问、会计师、律师）”
- “为 500 多名员工配置 SSO 的企业 IT 管理员”
- “以移动端为主、每周点 3 次以上外卖的千禧一代（25 至 35 岁）”
Agent 提供 3 个选项：
- 我已经有用户画像 — [参考
skills/proto-persona/SKILL.md或粘贴用户画像] - 帮我找出目标用户 — [Agent 提问：谁最能感受到这个业务问题？谁最可能采用？谁最容易触达？]
- 我需要先创建用户画像 — [Agent 建议使用
skills/proto-persona/SKILL.md组件技能]
用户回复： [选择或描述]
Agent 验证： 描述是否具体到可以想象出一个真实的人？还是太宽泛（“所有用户”）？
问题 4：用户成果与收益（方框 4）
Agent 提问：
用户为什么会寻求你的产品或服务？他们能获得什么收益？我们能观察到哪些行为变化，从而判断他们已实现目标？
重点关注目标、收益、情绪、共情，而不是指标（指标应填入方框 2）。
用户成果与收益示例：
- 每周减少 10 小时的手动数据录入时间（腾出更多时间陪伴家人）
- 更快交付项目，从而获得晋升
- 避免在朋友面前结账失败的尴尬
- 无需致电支持团队，也能有信心地配置企业软件
为什么这很重要：这是共情方框。它关注的是人的动机，而不只是行为变化。
Agent 提供 3 个选项：
- 我知道用户想实现什么 — [描述用户收益]
- 帮我识别用户收益 — [Agent 提示：他们雇用这个产品来完成什么任务？他们想避免什么痛点？他们想获得什么收益？]
- 我需要先做研究 — [Agent 建议查看
skills/jobs-to-be-done/SKILL.md或skills/discovery-interview-prep/SKILL.md]
用户回复：[选择或描述]
Agent 验证：这是否说明了用户为什么在意（而不仅是他们会做什么）？
问题 5：解决方案（方框 5）
Agent 提问：
我们可以打造什么，既能解决业务问题，又能同时满足客户需求？
列出可能奏效的功能、举措、政策、系统，甚至商业模式转变。鼓励广泛探索解决方案：无论大小、创新、“古怪”还是非技术方案。
示例：
- 一键式移动结账（Apple Pay、Google Pay）
- 自助式引导向导（无需人工配置）
- AI 驱动的推荐引擎
- 礼宾式引导（高接触、手动操作——先测试，再自动化）
- 更改定价模式（按使用量计费，而不是固定费率）
重要提示：这些都是假设，不是承诺。你是在探索选项，而不是承诺把所有方案都开发出来。
Agent 提供 3 个选项：
- 我有解决方案创意 — [列出候选解决方案]
- 帮我集思广益，想出解决方案 — [Agent 根据问题、成果和用户提出解决方案]
- 我只想到一个解决方案 — [Agent 追问：“还有什么方案可以解决这个问题？如果这个方案行不通怎么办？”]
用户回复：[选择或描述]
**Agent 验证：**你是否至少有 3 个候选解决方案？（选项越多，之后的假设就越好）
问题 6：假设（方框 6）
Agent 提问：
现在，让我们结合方框 2-5 中的假设，创建可测试的假设。
使用以下模板：
**我们相信，**如果[方框 3 中的用户]借助[方框 5 中的解决方案]实现[方框 4 中的收益]，就能达成[方框 2 中的业务成果]。
规则：
- 每个假设只针对一个解决方案（来自方框 5）
- 结合方框 2、3、4 和 5 中的假设
- 必须可测试（你能够设计实验来验证或证伪该假设）
示例：
我们相信，通过一键式 Apple Pay 集成，面向移动端优先的千禧一代用户（25-35 岁）实现更快、无摩擦的结账体验，就能将移动端结账转化率从 45% 提高到 60%。
Agent 提供：
根据你的输入，以下是建议的假设（方框 5 中的每个解决方案对应一个）：
- [生成的假设 1]
- [生成的假设 2]
- [生成的假设 3]
选项：
- 接受这些假设 — [Agent 记录这些假设]
- 编辑某个假设 — [修改措辞]
- 自行撰写假设 — [使用该模板]
用户回复：[选择或描述]
**Agent 验证：**每个假设是否都清楚说明了，如果解决方案奏效，你认为会发生什么？
问题 7：我们首先需要了解的最重要的事情是什么？（框 7）
Agent 提问：
针对框 6 中的每个假设，找出其风险最高的假设。然后确定当前风险最高的一项。
风险类型：
- 价值风险： 用户真的会使用它吗？他们在乎吗？
- 可用性风险： 用户能弄明白如何使用它吗？
- 可行性风险： 我们能在技术上实现它吗？
- 商业可行性风险： 这能实现业务目标吗？
提示： 在早期阶段，应更多关注价值风险，而非可行性风险（大多数时候如此）。不要构建用户不想要的东西，即使它在技术上可行。
Agent 提供：
根据你的假设，以下是风险最高的假设：
- [假设 1 的风险] — 例如：“用户会信任无需查看逐项费用的一键结账”
- [假设 2 的风险] — 例如：“自助式入门流程会将设置时间缩短至 <3 天”
- [假设 3 的风险] — 例如：“AI 推荐会使平均订单金额提升 50%”
当前风险最高的是哪一项？
选项：
- 风险 1 — [选择并说明原因]
- 风险 2 — [选择并说明原因]
- 风险 3 — [选择并说明原因]
- 我不确定哪项风险最高 — [Agent 帮助确定优先级：如果哪项假设不成立，会导致这项计划失败？]
用户回应： [选择]
Agent 记录： 这是我们将首先测试的假设。
问题 8：为了了解下一个最重要的事情，我们最少需要做多少工作？（框 8）
Agent 提问：
设计一项实验，以尽可能快的速度验证或证伪风险最高的假设（来自框 7）。
实验类型示例：
- 客户访谈 — 进行 5-10 次访谈，测试价值假设
- 落地页 — 通过虚设入口测试衡量兴趣
- 礼宾式服务 / 手动原型 — 先提供高接触、人工操作的版本，再进行自动化
- 绿野仙踪测试 — 假装功能已经存在（由幕后人员实际操作）
- 冒烟测试 — 宣布这项功能，衡量注册人数
提醒： 实验设计是一门艺术。画布会推动你去设计实验，但请做好单独迭代实验设计的准备。
Agent 提供：
根据风险最高的假设，以下是可选实验：
- 客户访谈 — 与 10 位用户交谈，询问他们是否会使用 [解决方案]，并观察他们目前采用的替代方案
- 落地页测试 — 创建一个介绍 [解决方案] 的落地页，衡量注册率
- 礼宾式服务测试 — 手动为 5 位用户提供 [收益]，观察他们是否实现了 [结果]
- 绿野仙踪原型 — 由幕后人员假装提供 [解决方案]，观察用户是否完成工作流
- 设计自定义实验 — [描述你的实验]
你将进行哪项实验？
用户回应： [选择一项或描述自定义实验]
Agent 验证： 这是能够验证或证伪该假设的最小测试吗？（如果需要超过 2 周，那就太大了——请拆分。）
步骤 9：检查并导出画布
Agent 总结：
这是你完成的精益 UX 画布（v2）：
┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2) │
│ Initiative: [Title] │
│ Date: [Today's date] │
│ Iteration: 1 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │ │ 2. Business Outcomes │
│ [Your input] │ │ [Your input] │
│ │ │ │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users │ │ 4. User Outcomes │
│ [Your input] │ [Your input] │ & Benefits │
│ │ │ [Your input] │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. Hypotheses │ 7. Learn │ 8. Experiments │
│ [Your input] │ First │ [Your input] │
│ │ [Your input] │ │
└─────────────────────┴──────────────┴───────────────────────┘
后续步骤：
- 进行实验（框 8） — 设定时间表（例如，2 周）
- 记录学习成果 — 你学到了什么？假设得到验证还是被证伪？
- 更新画布 — 根据学习成果修改假设，并选择下一个风险最高的假设
- 迭代 — 重复框 7 → 框 8，直到对构建产品有足够信心
Agent 提问：
你希望我：
- 将此画布导出为 Markdown 文件？
- 推荐接下来使用的相关技能（例如，客户访谈可使用
skills/discovery-interview-prep/SKILL.md）？ - 完善特定框（如果有内容感觉不完整）？
示例
完整的精益 UX 画布示例请参阅 examples/sample.md。
简短示例摘录：
**Box 1:** Mobile checkout conversion is 15% lower than desktop
**Box 2:** Increase mobile conversion from 45% to 60%
**Box 8:** Wizard-of-Oz test with one-tap checkout
常见陷阱
1. 从解决方案出发，而非问题
失败模式： 方框 1 写着“我们需要构建 X”，而不是描述发生了什么变化。
后果： 你构建的是别人已经决定好的解决方案，却没有验证问题是否真的存在。
修正： 询问：“世界发生了什么变化？为什么这个问题现在才出现（而不是 6 个月前）？”
2. 业务成果含糊不清
失败模式： 方框 2 写着“增加收入”或“让用户满意”。
后果： 无法衡量成功，也无法判断实验是否奏效。
修正： 明确可衡量的行为变化。例如：“将平均订单金额从 $50 提高到 $75”或“将支持工单减少 30%”。
3. 用户群体范围过广
失败模式： 方框 3 写着“所有用户”或“每个人”。
后果： 无法设计有针对性的实验；还会把时间浪费在不会采用产品的用户画像上。
修正： 先选定一个用户画像。之后可以再扩大范围。
4. 混淆方框 2 和方框 4
失败模式： 把情绪写进方框 2，把指标写进方框 4（或反过来）。
后果： 假设彼此不一致；成功标准不明确。
修正： 方框 2 = 行为变化（指标）。 方框 4 = 目标、收益、情绪（共情）。
5. 方框 5 中只有一个解决方案
失败模式： 因为利益相关者已经做出决定，所以只列出一项功能。
后果： 没有探索其他方案；也无法测试哪种方案最好。
修正： 强迫自己列出至少 3 个解决方案。问问自己：“还有什么其他办法能解决这个问题？”
6. 跳过实验（方框 8）
失败模式： “我们直接构建出来看看会发生什么。”
后果： 花费数周或数月构建了错误的东西。
修正： 先设计最小规模的实验。如果想不到实验，可以使用 skills/pol-probe-advisor/SKILL.md 来选择验证方法。
参考资料
相关技能
- problem-statement（组件）— 填写方框 1 前，先明确问题
- problem-framing-canvas（交互式）— 在使用画布前进行 MITRE 问题界定
- proto-persona（组件）— 为方框 3 创建用户画像
- jobs-to-be-done（组件）— 识别方框 4 中的用户收益
- epic-hypothesis（组件）— 编写可测试的假设（方框 6）
- discovery-interview-prep（交互式）— 为方框 8 设计客户访谈
- pol-probe-advisor（交互式）— 为方框 8 选择实验类型
外部框架
- Jeff Gothelf — Lean UX: Designing Great Products with Agile Teams（O'Reilly，2013；第 2 版，2016）
- Jeff Gothelf — Lean UX Canvas v2（官方博客文章）
- Lean UX Canvas PDF — 下载 v2 PDF
工具
- Miro / Mural — 用于协作填写画布的数字白板
- Google Slides / PowerPoint — 可从 Jeff Gothelf 的网站获取模板
- Notion / Coda — 用于跟踪多个画布的数据库视图