lean-ux-canvas by deanpeters/product-manager-skills
npx skills add https://github.com/deanpeters/product-manager-skills --skill lean-ux-canvas指导产品经理创建 Jeff Gothelf 的精益用户体验画布 (v2) —— 一个一页纸的引导工具,将工作围绕要解决的业务问题展开,而不是要实施的解决方案。使用此工具来协调跨职能团队围绕核心假设,制定可测试的假设,并通过揭示理解上的差距(问题、用户、价值以及解决方案为何有效)来确保每个冲刺周期都有所学习。
这不是路线图或功能列表——这是一份**"保险单",在投入全面开发之前将假设转化为实验。该画布将对话从输出转向成果**,并确保团队构建正确的东西,而不仅仅是正确地构建东西。
精益用户体验画布 (v2) 是一个结构化的一页纸模板,旨在帮助团队围绕业务问题(而非解决方案)来构建工作。它使跨职能团队在以下方面达成一致:
起源: 由《精益用户体验》(O'Reilly,2013年)作者 Jeff Gothelf 创建。第 2 版发布是为了提高业务成果与用户成果之间的清晰度。
核心见解: 该画布就像一份保险单——它在您构建之前揭示理解上的差距,确保您不会在错误的事情上浪费冲刺周期。
布局(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 │ │
└─────────────────────┴──────────────┴───────────────────────┘
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
8个方格(按此顺序填写):
问题优先,而非解决方案优先: 从"世界上发生了什么变化?"开始,而不是"我们应该构建 X"。这防止了解决方案驱动的思维。
假设驱动: 在构建之前明确假设。每个学科都揭示其风险(技术可行性、用户价值、业务可行性)。
聚焦实验: 在投入资源之前测试假设。小实验胜过豪赌。
跨职能对齐: 共享画布创造了共同语言。每个人都能看到相同的理解差距。
方格 2(业务成果)与方格 4(用户成果):
方格 2 是度量指标。方格 4 是人性。
解决方案(方格 5)是假设,而非承诺: 列出候选解决方案(功能、策略,甚至是商业模式转变)。您并非承诺构建所有方案——您是在探索解决方案空间。
假设(方格 6)是可测试的: 使用模板:"我们相信,如果[用户]通过[解决方案]获得[收益],那么[业务成果]将会实现。" 每个假设都聚焦于一个解决方案。
✅ 在以下情况使用:
❌ 不要在以下情况使用:
使用 workshop-facilitation 作为此技能的默认交互协议。
它定义了:
Other (specify))此文件定义了特定领域的评估内容。如果存在冲突,请遵循此文件的领域逻辑。
使用 template.md 获取完整的填写结构。
此交互式技能按顺序引导您完成 8 个自适应问题(每个画布方格一个)。在每个步骤中,智能体会提供指导、示例和选项,帮助您正确填写方格。
智能体询问:
在填写精益用户体验画布之前,让我们收集一些上下文。请分享:
业务上下文:
用户上下文:
您可以粘贴:
智能体询问:
您试图解决的业务问题是什么?
描述:
好的例子:
不好的例子(太模糊):
智能体提供 3 个选项:
skills/problem-statement/SKILL.md 或 skills/problem-framing-canvas/SKILL.md]用户响应: [选择或描述]
智能体验证: 这描述了变化以及为什么它造成了问题吗?如果没有,请询问澄清性问题。
智能体询问:
您如何知道业务问题已解决?您将衡量什么?
专注于可衡量的行为变化(欢迎领先指标)。问自己:"如果解决方案有效,人们的行为会有什么不同?"
业务成果示例:
重要提示: 这是方格 2(行为变化),不是方格 4(用户收益/同理心)。度量指标放在这里。情感放在方格 4。
智能体提供 3 个选项:
用户响应: [选择或描述]
智能体验证: 这些是可衡量的吗?可观察的吗?它们指示行为变化吗(不仅仅是"增加收入")?
智能体询问:
您应该首先关注哪些类型(即用户画像)的用户和客户?
考虑:
为什么重要: 团队倾向于在这里走捷径("所有人")。画布需要一个关于用户的共同愿景——而且它并不总是"客户"。
示例:
智能体提供 3 个选项:
skills/proto-persona/SKILL.md 或粘贴用户画像]skills/proto-persona/SKILL.md 组件技能]用户响应: [选择或描述]
智能体验证: 这足够具体到可以想象一个真实的人吗?还是太宽泛("所有用户")?
智能体询问:
您的用户为什么会寻求您的产品或服务?他们会获得什么好处?我们可以观察到哪些行为变化,告诉我们他们已经实现了目标?
专注于目标、收益、情感、同理心——而不是指标(那些放在方格 2)。
用户成果与收益示例:
为什么重要: 这是同理心方格。它关乎人的动机,而不仅仅是行为变化。
智能体提供 3 个选项:
skills/jobs-to-be-done/SKILL.md 或 skills/discovery-interview-prep/SKILL.md]用户响应: [选择或描述]
智能体验证: 这解释了用户为什么在乎吗(不仅仅是他们会做什么)?
智能体询问:
我们可以制作什么来同时解决我们的业务问题并满足客户的需求?
列出可能有效的功能、举措、策略、系统,甚至是商业模式转变。鼓励广泛的解决方案空间:大/小、创新、"奇怪"和非技术性的解决方案。
示例:
重要提示: 这些是假设,不是承诺。您是在探索选项,而不是承诺构建所有内容。
智能体提供 3 个选项:
用户响应: [选择或描述]
智能体验证: 您至少有 3 个候选解决方案吗?(更多选项 = 后续更好的假设)
智能体询问:
现在让我们通过结合方格 2-5 的假设来创建可测试的假设。
使用此模板:
我们相信 [来自方格 2 的业务成果] 将会实现,如果 [来自方格 3 的用户] 通过 [来自方格 5 的解决方案] 获得 [来自方格 4 的收益]。
规则:
示例:
我们相信 将移动端结账转化率从 45% 提高到 60% 将会实现,如果 移动优先的千禧一代(25-35 岁) 通过 一键 Apple Pay 集成 获得 更快、无摩擦的结账体验。
智能体提供:
根据您的输入,以下是建议的假设(每个方格 5 的解决方案一个):
选项:
用户响应: [选择或描述]
智能体验证: 每个假设是否清楚地说明了如果解决方案有效,您相信会发生什么?
智能体询问:
对于方格 6 中的每个假设,识别其最冒险的假设。然后确定当前最冒险的一个。
风险类型:
提示: 早期,更多地关注价值风险而非可行性风险(大多数情况下)。不要构建用户不想要的东西,即使它在技术上是可行的。
智能体提供:
根据您的假设,以下是最冒险的假设:
当前哪个最冒险?
选项:
用户响应: [选择]
智能体记录: 这是我们将首先测试的假设。
智能体询问:
设计一个实验,以尽可能快地验证或推翻最冒险的假设(来自方格 7)。
实验类型示例:
提醒: 实验设计是一门艺术。画布促使您去做——期望您单独迭代实验设计。
智能体提供:
根据您最冒险的假设,以下是实验选项:
您将运行哪个实验?
用户响应: [选择一个或描述自定义实验]
智能体验证: 这是验证/推翻该假设的最小测试吗?(如果超过 2 周,就太大了——分解它。)
智能体总结:
这是您完成的精益用户体验画布 (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] │ │
└─────────────────────┴──────────────┴───────────────────────┘
后续步骤:
智能体询问:
您希望我:
skills/discovery-interview-prep/SKILL.md 用于客户访谈)?查看 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 写着"我们需要构建 X",而不是描述发生了什么变化。
后果: 您构建了别人已经决定的解决方案,而没有验证问题是否存在。
修复: 提问:"世界上发生了什么变化?为什么现在(与 6 个月前相比)这是一个问题?"
失败模式: 方格 2 写着"增加收入"或"让用户开心"。
后果: 无法衡量成功;无法判断实验是否有效。
修复: 定义可衡量的行为变化。"将平均订单价值从 50 美元提高到 75 美元"或"将支持工单减少 30%"。
失败模式: 方格 3 写着"所有用户"或"每个人"。
后果: 无法设计有针对性的实验;在不会采用的用户画像上浪费时间。
修复: 先选择一个用户画像。以后可以扩展。
失败模式: 将情感放在方格 2,将指标放在方格 4(或反之)。
后果: 假设不一致;成功标准不明确。
修复: 方格 2 = 行为变化(指标)。 方格 4 = 目标、收益、情感(同理心)。
失败模式: 因为利益相关者已经决定,只列出一个功能。
后果: 没有探索替代方案;无法测试哪个解决方案最好。
修复: 强迫自己列出 3 个以上的解决方案。提问:"还有什么可以解决这个问题?"
失败模式: "我们就构建它,看看会发生什么。"
后果: 浪费数周/数月构建错误的东西。
修复: 首先设计最小的实验。如果您想不出,请使用 skills/pol-probe-advisor/SKILL.md 来选择验证方法。
每周安装量
390
仓库
GitHub 星标
2.3K
首次出现
2026年2月12日
安全审计
安装于
codex349
opencode342
gemini-cli338
github-copilot338
cursor337
kimi-cli334
Guide product managers through creating Jeff Gothelf's Lean UX Canvas (v2) —a one-page facilitation tool that frames work around a business problem to solve , not a solution to implement. Use this to align cross-functional teams around core assumptions, craft testable hypotheses, and ensure learning happens every sprint by exposing gaps in understanding (problem, users, value, and why the solution should work).
This is not a roadmap or feature list—it's an "insurance policy" that turns assumptions into experiments before committing to full development. The canvas shifts conversations from outputs to outcomes and ensures teams build the right thing, not just build things right.
The Lean UX Canvas (v2) is a structured, one-page template designed to help teams frame their work around a business problem, not a solution. It aligns cross-functional teams on:
Origin: Created by Jeff Gothelf, author of Lean UX (O'Reilly, 2013). Version 2 was released to improve clarity around business vs. user outcomes.
Key Insight: The canvas acts like an insurance policy —it exposes gaps in understanding before you build, ensuring you don't waste sprints on the wrong thing.
Layout (3 columns × 3 rows):
┌─────────────────────┬──────────────┬───────────────────────┐
│ 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 │ │
└─────────────────────┴──────────────┴───────────────────────┘
The 8 Boxes (fill in this order):
Problem-First, Not Solution-First: Starts with "what changed in the world?" not "we should build X." This prevents solution-driven thinking.
Assumption-Driven: Makes hypotheses explicit before building. Every discipline surfaces their risks (technical feasibility, user value, business viability).
Experiment-Focused: Tests assumptions before committing resources. Small experiments beat big bets.
Cross-Functional Alignment: Shared canvas creates common language. Everyone sees the same gaps in understanding.
Box 2 (Business Outcomes) vs. Box 4 (User Outcomes):
Box 2 is metrics. Box 4 is human.
Solutions (Box 5) Are Hypotheses, Not Commitments: List candidate solutions (features, policies, even business model shifts). You're not committing to build all of them—you're exploring the solution space.
Hypotheses (Box 6) Are Testable: Use the template: "We believe [business outcome] will be achieved if [user] attains [benefit] with [solution]." Each hypothesis focuses on one solution.
✅ Use this when:
❌ Don't use this when:
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
Use template.md for the full fill-in structure.
This interactive skill walks through 8 adaptive questions (one per canvas box) in sequence. At each step, the agent offers guidance, examples, and options to help you fill the box correctly.
Agent asks:
Before we fill out the Lean UX Canvas, let's gather context. Please share:
Business Context:
User Context:
You can paste:
Agent asks:
What problem does the business have that you are trying to solve?
Describe:
Good examples:
Bad examples (too vague):
Agent offers 3 options:
skills/problem-statement/SKILL.md or skills/problem-framing-canvas/SKILL.md first]User response: [Selection or description]
Agent validates: Does this describe what changed and why it creates a problem? If not, ask clarifying questions.
Agent asks:
How will you know you solved the business problem? What will you measure?
Focus on measurable behavior change (leading indicators welcome). Ask yourself: "What will people be doing differently if the solution works?"
Examples of business outcomes:
Important: This is Box 2 (behavior change) , not Box 4 (user benefits/empathy). Metrics go here. Emotions go in Box 4.
Agent offers 3 options:
User response: [Selection or description]
Agent validates: Are these measurable? Observable? Do they indicate behavior change (not just "increase revenue")?
Agent asks:
What types (i.e., personas) of users and customers should you focus on first?
Consider:
Why this matters: Teams tend to shortcut here ("everyone"). The canvas wants a shared vision of the user—and it's not always "the customer."
Examples:
Agent offers 3 options:
skills/proto-persona/SKILL.md or paste persona]skills/proto-persona/SKILL.md component skill]User response: [Selection or description]
Agent validates: Is this specific enough to imagine a real person? Or is it too broad ("all users")?
Agent asks:
Why would your users seek out your product or service? What benefit would they gain? What behavior change can we observe that tells us they've achieved their goal?
Focus on goals, benefits, emotions, empathy —not metrics (those go in Box 2).
Examples of user outcomes & benefits:
Why this matters: This is the empathy box. It's about human motivation, not just behavior change.
Agent offers 3 options:
skills/jobs-to-be-done/SKILL.md or skills/discovery-interview-prep/SKILL.md]User response: [Selection or description]
Agent validates: Does this explain why the user cares (not just what they'll do)?
Agent asks:
What can we make that will solve our business problem and meet the needs of our customers at the same time?
List features, initiatives, policies, systems, or even business model shifts that might work. Encourage a wide solution space: big/small, innovative, "weird," and non-technical solutions.
Examples:
Important: These are hypotheses , not commitments. You're exploring options, not committing to build everything.
Agent offers 3 options:
User response: [Selection or description]
Agent validates: Do you have at least 3 candidate solutions? (More options = better hypotheses later)
Agent asks:
Now let's create testable hypotheses by combining assumptions from Boxes 2-5.
Use this template:
We believe that [business outcome from Box 2] will be achieved if [user from Box 3] attains [benefit from Box 4] with [solution from Box 5].
Rules:
Example:
We believe that increasing mobile checkout conversion rate from 45% to 60% will be achieved if mobile-first millennials (25-35) attain faster, friction-free checkout with one-tap Apple Pay integration.
Agent offers:
Based on your inputs, here are suggested hypotheses (one per solution from Box 5):
Options:
User response: [Selection or description]
Agent validates: Does each hypothesis clearly state what you believe will happen if the solution works?
Agent asks:
For each hypothesis from Box 6, identify its riskiest assumptions. Then determine the riskiest one right now.
Types of risk:
Hint: Early on, focus risk on value more than feasibility (most of the time). Don't build something users don't want, even if it's technically feasible.
Agent offers:
Based on your hypotheses, here are the riskiest assumptions:
Which is the riskiest right now?
Options:
User response: [Selection]
Agent records: This is the assumption we'll test first.
Agent asks:
Design an experiment to validate or invalidate the riskiest assumption (from Box 7) as fast as you can.
Examples of experiment types:
Reminder: Experiment design is an art. The canvas nudges you to do it—expect to iterate on the experiment design separately.
Agent offers:
Based on your riskiest assumption, here are experiment options:
Which experiment will you run?
User response: [Select one or describe custom experiment]
Agent validates: Is this the smallest test that can validate/invalidate the assumption? (If it takes >2 weeks, it's too big—break it down.)
Agent summarizes:
Here's your completed Lean UX Canvas (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] │ │
└─────────────────────┴──────────────┴───────────────────────┘
Next steps:
Agent asks:
Would you like me to:
skills/discovery-interview-prep/SKILL.md for customer interviews)?See examples/sample.md for full Lean UX Canvas examples.
Mini example excerpt:
**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
Failure Mode: Box 1 says "We need to build X" instead of describing what changed.
Consequence: You build the solution someone already decided on, without validating the problem exists.
Fix: Ask: "What changed in the world? Why is this a problem now (vs. 6 months ago)?"
Failure Mode: Box 2 says "Increase revenue" or "Make users happy."
Consequence: No way to measure success; can't tell if experiments worked.
Fix: Define measurable behavior change. "Increase average order value from $50 to $75" or "Reduce support tickets by 30%."
Failure Mode: Box 3 says "All users" or "Everyone."
Consequence: Can't design targeted experiments; waste time on personas who won't adopt.
Fix: Pick one persona to start. You can expand later.
Failure Mode: Putting emotions in Box 2 and metrics in Box 4 (or vice versa).
Consequence: Misaligned hypotheses; unclear success criteria.
Fix: Box 2 = Behavior change (metrics). Box 4 = Goals, benefits, emotions (empathy).
Failure Mode: Listing one feature because stakeholders already decided.
Consequence: No exploration of alternatives; can't test which solution is best.
Fix: Force yourself to list 3+ solutions. Ask: "What else could solve this problem?"
Failure Mode: "We'll just build it and see what happens."
Consequence: Waste weeks/months building the wrong thing.
Fix: Design smallest experiment first. If you can't think of one, use skills/pol-probe-advisor/SKILL.md to choose a validation method.
Weekly Installs
390
Repository
GitHub Stars
2.3K
First Seen
Feb 12, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex349
opencode342
gemini-cli338
github-copilot338
cursor337
kimi-cli334
注册流程转化率优化指南:减少摩擦、提高完成率的专家技巧
24,500 周安装