名称: lean-ux-canvas 描述: 引导产品经理通过Jeff Gothelf的Lean UX Canvas v2——一个单页工具，围绕业务问题框架工作，暴露假设，并确保每个冲刺都有学习。 类型: 交互式
目的
引导产品经理创建Jeff Gothelf的Lean UX Canvas (v2)——一个单页引导工具，围绕要解决的业务问题框架工作，而不是要实施的解决方案。使用这个来对齐跨职能团队围绕核心假设，制定可测试的假设，并通过暴露理解上的差距（问题、用户、价值以及解决方案为什么应该有效）确保每个冲刺都有学习。
这不是一个路线图或功能列表——它是一个**“保险政策”，在承诺全面开发之前将假设转化为实验。画布将对话从输出转向成果**，并确保团队构建正确的东西，而不仅仅是正确地构建东西。
关键概念
什么是Lean UX Canvas？
Lean UX Canvas (v2) 是一个结构化的单页模板，旨在帮助团队围绕业务问题而非解决方案框架工作。它对齐跨职能团队在：
- 存在什么问题（以及为什么现在重要）
- 什么是可衡量的成功指标
- 我们为谁解决
- 我们做出什么假设
- 我们需要先学习什么
- 什么实验将测试这些假设
起源: 由Jeff Gothelf创建，他是Lean UX（O’Reilly，2013）的作者。版本2发布以提高围绕业务与用户成果的清晰度。
关键洞察: 画布就像一个保险政策——它在构建之前暴露理解上的差距，确保你不会在错误的东西上浪费冲刺。
画布结构（8个框）
布局（3列 × 3行）：
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. 业务问题 │ │ 2. 业务成果 │
│ │ │ │
├─────────────────────┤ 5. 解决方案 ├───────────────────────┤
│ 3. 用户 │ (高框跨越 │ 4. 用户成果 │
│ │ 行1-2) │ 与好处 │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. 假设 │ 7. 首先学习 │ 8. 最少工作/ │
│ │ │ 实验 │
│ │ │ │
└─────────────────────┴──────────────┴───────────────────────┘
8个框（按此顺序填写）：
- 业务问题 —— 世界上发生了什么变化，导致了一个值得解决的问题？
- 业务成果 —— 什么可衡量的行为改变表明成功？
- 用户 —— 你应该首先关注哪个人物角色？
- 用户成果与好处 —— 为什么用户会寻求这个？他们获得什么好处？
- 解决方案 —— 什么功能/倡议可能解决问题并满足用户需求？
- 假设 —— 可测试的假设，结合框2-5（如果/那么格式）
- 首先最重要学习什么？ —— 当前最风险的单一假设
- 学习下一个最重要东西最少需要做什么工作？ —— 最小实验来验证/推翻那个假设
为什么这有效
问题为先，而非解决方案为先： 从“世界上发生了什么变化？”开始，而不是“我们应该构建X。”这防止解决方案驱动的思维。
假设驱动： 在构建之前使假设显式。每个学科都暴露其风险（技术可行性、用户价值、业务可行性）。
实验聚焦： 在承诺资源之前测试假设。小实验胜过大胆赌注。
跨职能对齐： 共享画布创建共同语言。每个人都看到理解上的相同差距。
关键区别（避免混淆）
框2（业务成果）与框4（用户成果）：
- 框2： 可衡量的行为改变（留存率、网站时间、平均订单价值）
- 框4： 目标、好处、情感、同理心（省钱、晋升、与家人共度时光）
框2是指标。框4是人性化。
解决方案（框5）是假设，而非承诺： 列出候选解决方案（功能、政策，甚至业务模式转变）。你不是承诺构建所有——你是在探索解决方案空间。
假设（框6）是可测试的： 使用模板：“我们相信[业务成果]将通过如果[用户]使用[解决方案]获得[好处]实现。”每个假设聚焦于一个解决方案。
反模式（这不是什么）
- 不是功能列表： 解决方案是要测试的想法，不是待办事项
- 不是项目计划： 画布框架学习，不是交付时间表
- 不是战略替代： 画布执行战略；它不创造战略
- 不是一次性练习： 随着学习重新访问；更新假设
何时使用
✅ 使用当：
- 启动新产品倡议或功能
- 重新框架现有项目（怀疑你在构建错误的东西）
- 对齐跨职能团队在假设和实验上
- 规划发现冲刺或MVP
- 利益相关者是解决方案驱动的（“我们需要构建X”）并且你需要暴露假设
❌ 不使用当：
- 问题和解决方案已经验证（转向执行）
- 战术性错误修复或技术债务（无需学习）
- 利益相关者已承诺解决方案，无论证据如何（先解决对齐）
引导真相源
使用workshop-facilitation作为此技能的默认交互协议。
它定义：
- 会议准备 + 进入模式（引导、上下文转储、最佳猜测）
- 单问题回合，用简单语言提示
- 进度标签（例如，上下文 Qx/8 和评分 Qx/5）
- 中断处理和暂停/恢复行为
- 决策点的编号建议
- 常规问题的快速选择编号响应选项（包括
其他（指定）当有用时）
此文件定义领域特定评估内容。如有冲突，遵循此文件的领域逻辑。
应用
使用template.md获取完整的填充结构。
此交互式技能按顺序引导8个自适应问题（每个画布框一个）。在每个步骤中，代理提供指导、示例和选项以帮助你正确填写框。
步骤0：收集上下文
代理询问：
在填写Lean UX Canvas之前，让我们收集上下文。请分享：
业务上下文：
- 利益相关者请求、产品简报或倡议描述
- 业务指标（收入、流失、增长目标、KPIs）
- 战略目标（OKRs、路线图优先级）
用户上下文：
- 客户研究、人物角色、JTBD洞察
- 用户反馈、支持票、流失原因
- 竞品分析、市场趋势
你可以粘贴：
- PRD或产品简报
- 利益相关者备忘录
- 用户研究摘要
- 或简要描述倡议
问题1：业务问题（框1）
代理询问：
企业有什么问题你试图解决？
描述：
- 当前状态： 企业今天如何交付价值？
- 什么改变： 市场变化、竞争威胁、客户行为改变、新交付渠道
- 为什么重要： 为什么当前情况不满足期望？
好例子：
- “我们移动流量超过桌面后，结账转换率下降了15%。我们的结账流程不是为移动设计，竞争对手有一键结账。”
- “企业客户在6个月后流失，因为我们的上机过程需要3+周的手动配置。竞争对手提供自服务上机。”
坏例子（太模糊）：
- “我们需要增加收入”（无上下文什么改变）
- “用户想要更多功能”（未陈述业务问题）
代理提供3个选项：
- 我将描述业务问题 —— [粘贴或写入描述]
- 帮助我识别业务问题 —— [代理询问后续问题：什么改变？什么指标受影响？竞争对手在做什么？]
- 我不确定业务问题是什么 —— [代理建议先用
skills/problem-statement/SKILL.md或skills/problem-framing-canvas/SKILL.md]
用户响应： [选择或描述]
代理验证： 这描述什么改变以及为什么创造问题？如果没有，询问澄清问题。
问题2：业务成果（框2）
代理询问：
你将如何知道解决了业务问题？你将测量什么？
聚焦可衡量的行为改变（欢迎先导指标）。问自己：“如果解决方案有效，人们将做什么不同？”
业务成果示例：
- 增加移动结账转换率从45%到60%
- 减少企业上机时间从3周到3天
- 增加平均订单价值从$50到$75
- 减少客户支持票30%
- 增加免费转付费转换率从5%到10%
重要： 这是框2（行为改变），不是框4（用户好处/同理心）。指标在此。情感在框4。
代理提供3个选项：
- 我有具体指标 —— [陈述业务成果]
- 帮助我定义可衡量成果 —— [代理基于业务问题建议指标]
- 我只有滞后指标（收入、利润） —— [代理帮助识别预测这些成果的先导指标]
用户响应： [选择或描述]
代理验证： 这些可衡量吗？可观察吗？指示行为改变（不仅仅是“增加收入”）？
问题3：用户（框3）
代理询问：
你应该首先关注什么类型的用户和客户（即人物角色）？
考虑：
- 谁购买？
- 谁使用？
- 谁配置？
- 谁管理？
为什么重要： 团队倾向于在此走捷径（“所有人”）。画布想要一个共享用户愿景——并且不总是“客户”。
例子：
- “SMB所有者（1-10员工）在专业服务（顾问、会计师、律师）”
- “企业IT管理员，为500+员工配置SSO”
- “移动优先千禧一代（25-35），每周点外卖3+次”
代理提供3个选项：
- 我已经有人物角色 —— [参考
skills/proto-persona/SKILL.md或粘贴人物角色] - 帮助我识别目标用户 —— [代理询问：谁最常经历业务问题？谁最可能采用？谁最容易接触？]
- 我需要先创建人物角色 —— [代理建议使用
skills/proto-persona/SKILL.md组件技能]
用户响应： [选择或描述]
代理验证： 这足够具体到想象一个真实人吗？还是太宽（“所有用户”）？
问题4：用户成果与好处（框4）
代理询问：
为什么你的用户会寻求你的产品或服务？他们会获得什么好处？我们可以观察什么行为改变来告诉我们他们实现了目标？
聚焦目标、好处、情感、同理心——不是指标（那些在框2）。
用户成果与好处示例：
- 每周节省10小时手动数据输入（花更多时间与家人）
- 通过更快交付项目获得晋升
- 避免在朋友面前结账失败的尴尬
- 感觉有信心配置企业软件无需呼叫支持
为什么重要： 这是同理心框。它是关于人类动机，而不仅仅是行为改变。
代理提供3个选项：
- 我知道用户想实现什么 —— [描述用户好处]
- 帮助我识别用户好处 —— [代理提示：他们雇佣这个产品做什么工作？他们在避免什么痛苦？他们在寻求什么收获？]
- 我需要先研究这个 —— [代理建议
skills/jobs-to-be-done/SKILL.md或skills/discovery-interview-prep/SKILL.md]
用户响应： [选择或描述]
代理验证： 这解释为什么用户关心（不仅仅是他们会做什么）？
问题5：解决方案（框5）
代理询问：
我们可以制造什么来同时解决业务问题并满足客户需求？
列出功能、倡议、政策、系统，甚至业务模式转变，可能有效。鼓励广泛解决方案空间：大/小、创新、“怪异”和非技术解决方案。
例子：
- 一键移动结账（Apple Pay、Google Pay）
- 自服务上机向导（无人类配置）
- AI驱动推荐引擎
- 礼宾上机（高接触、手动——自动化前测试）
- 改变定价模式（基于用量而非固定费率）
重要： 这些是假设，不是承诺。你在探索选项，不是承诺构建一切。
代理提供3个选项：
- 我有解决方案想法 —— [列出候选解决方案]
- 帮助我头脑风暴解决方案 —— [代理基于问题、成果和用户建议解决方案]
- 我只有一个解决方案在脑中 —— [代理挑战：“还有什么能解决这个？如果那个解决方案无效？”]
用户响应： [选择或描述]
代理验证： 你至少有三个候选解决方案吗？（更多选项=以后更好假设）
问题6：假设（框6）
代理询问：
现在让我们通过结合框2-5的假设创建可测试假设。
使用此模板：
我们相信 [框2的业务成果] 将通过如果 [框3的用户] 使用 [框5的解决方案] 获得 [框4的好处] 实现。
规则：
- 每个假设聚焦于一个解决方案（来自框5）
- 结合框2、3、4、5的假设
- 必须可测试（你可以设计实验来验证/推翻）
例子：
我们相信 增加移动结账转换率从45%到60% 将通过如果 移动优先千禧一代（25-35） 使用 一键Apple Pay集成 获得 更快、无摩擦结账 实现。
代理提供：
基于你的输入，这里是建议假设（每个框5解决方案一个）：
- [生成的假设1]
- [生成的假设2]
- [生成的假设3]
选项：
- 接受这些假设 —— [代理记录]
- 编辑假设 —— [修改措辞]
- 写我自己的假设 —— [使用模板]
用户响应： [选择或描述]
代理验证： 每个假设清楚地陈述如果你相信解决方案有效会发生什么？
问题7：首先最重要学习什么？（框7）
代理询问：
对于框6的每个假设，识别其最风险假设。然后确定当前最风险的单一假设。
风险类型：
- 价值风险： 用户实际会使用这个吗？他们关心吗？
- 可用性风险： 用户能弄清楚如何使用吗？
- 可行性风险： 我们能技术上构建这个吗？
- 可行性风险： 这将实现业务成果吗？（注：原文为viability，译为业务可行性）
提示： 早期，更聚焦风险在价值而非可行性（大多数时间）。不要构建用户不想要的东西，即使技术上可行。
代理提供：
基于你的假设，这里是最风险假设：
- [假设1风险] —— 例如，“用户会信任一键结账无需看到项目化费用”
- [假设2风险] —— 例如，“自服务上机将减少设置时间到<3天”
- [假设3风险] —— 例如，“AI推荐将增加平均订单价值50%”
哪个当前最风险？
选项：
- 风险1 —— [选择并解释为什么]
- 风险2 —— [选择并解释为什么]
- 风险3 —— [选择并解释为什么]
- 我不确定哪个最风险 —— [代理帮助优先：哪个假设，如果错，会杀死倡议？]
用户响应： [选择]
代理记录： 这是我们将首先测试的假设。
问题8：学习下一个最重要东西最少需要做什么工作？（框8）
代理询问：
设计一个实验来验证或推翻最风险假设（来自框7）尽可能快。
实验类型例子：
- 客户访谈 —— 5-10次访谈测试价值假设
- 落地页 —— 假门测试测量兴趣
- 礼宾/手动原型 —— 高接触、手动版本在自动化前
- 巫师奥兹 —— 假装功能存在（人类幕后）
- 烟雾测试 —— 宣布功能，测量注册
提醒： 实验设计是一门艺术。画布推动你去做——期望在实验设计上单独迭代。
代理提供：
基于你最风险假设，这里是实验选项：
- 客户访谈 —— 与10个用户交谈，询问他们会使用[解决方案]吗，观察他们当前的工作方法
- 落地页测试 —— 创建描述[解决方案]的落地页，测量注册率
- 礼宾测试 —— 手动交付[好处]给5个用户，观察他们是否实现[成果]
- 巫师奥兹原型 —— 假[解决方案]与人类幕后，看用户是否完成工作流程
- 设计自定义实验 —— [描述你的实验]
你将运行哪个实验？
用户响应： [选择一个或描述自定义实验]
代理验证： 这是可以验证/推翻假设的最小测试吗？（如果花费>2周，太大——分解）
步骤9：审查和导出画布
代理总结：
这是你完成的Lean UX Canvas (v2)：
┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2) │
│ 倡议： [标题] │
│ 日期： [今天日期] │
│ 迭代： 1 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. 业务问题 │ │ 2. 业务成果 │
│ [你的输入] │ │ [你的输入] │
│ │ │ │
├─────────────────────┤ 5. 解决方案 ├───────────────────────┤
│ 3. 用户 │ │ 4. 用户成果 │
│ [你的输入] │ [你的输入] │ 与好处 │
│ │ │ [你的输入] │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. 假设 │ 7. 首先学习 │ 8. 实验 │
│ [你的输入] │ [你的输入] │ [你的输入] │
│ │ │ │
└─────────────────────┴──────────────┴───────────────────────┘
下一步：
- 运行实验（框8） —— 设置时间线（例如，2周）
- 记录学习 —— 你学到了什么？假设被验证或推翻？
- 更新画布 —— 基于学习修订假设，选择下一个最风险假设
- 迭代 —— 重复框7 → 框8直到信心足够高构建
代理询问：
你想我：
- 导出这个画布 为Markdown文件？
- 建议相关技能 下一步使用（例如，
skills/discovery-interview-prep/SKILL.md用于客户访谈）？ - 精炼特定框 （如果感觉不完整）？
例子
看examples/sample.md获取完整Lean UX Canvas例子。
迷你例子摘录：
**框1：** 移动结账转换比桌面低15%
**框2：** 增加移动转换从45%到60%
**框8：** 巫师奥兹测试与一键结账
常见陷阱
1. 从解决方案开始，而非问题
失败模式： 框1说“我们需要构建X”而不是描述什么改变。
后果： 你构建某人已经决定的解决方案，而没有验证问题存在。
修复： 询问：“世界上发生了什么变化？为什么这是现在的问题（vs 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; 2nd ed. 2016）
- Jeff Gothelf —— Lean UX Canvas v2（官方博客文章）
- Lean UX Canvas PDF —— 下载v2 PDF
工具
- Miro / Mural —— 数字白板用于协作画布填充
- Google Slides / PowerPoint —— Jeff Gothelf网站可用模板
- Notion / Coda —— 数据库视图用于跟踪多个画布