Back to Details

lean-ux-canvas

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

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.
引导产品经理创建Jeff Gothelf的Lean UX Canvas (v2)——这是一款单页协作工具，围绕需要解决的业务问题而非要实施的解决方案展开工作。通过它让跨职能团队在核心假设上达成共识，制定可测试的假设，并通过暴露认知差距（问题、用户、价值及解决方案可行的原因）确保每个冲刺周期都能实现学习。
它不是路线图或功能列表——而是一份**「保险单」，在投入全面开发前将假设转化为实验。该画布将对话从产出转向成果**，确保团队打造正确的产品，而非仅仅正确地打造产品。

Key Concepts

核心概念

What is the Lean UX Canvas?

什么是Lean UX Canvas？

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:
  • What problem exists (and why it matters now)
  • What measurable outcomes indicate success
  • Who we're solving for
  • What assumptions we're making
  • What we need to learn first
  • What experiments will test those assumptions
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.
Lean UX Canvas (v2) 是一个结构化的单页模板，旨在帮助团队围绕业务问题而非解决方案开展工作。它让跨职能团队在以下方面达成共识：
  • 存在什么问题（以及为何现在至关重要）
  • 哪些可衡量的成果标志着成功
  • 我们为谁解决问题
  • 我们做出了哪些假设
  • 我们首先需要了解什么
  • 哪些实验可以验证这些假设
起源： 由《Lean UX》（O'Reilly，2013）作者Jeff Gothelf创建。版本2的发布是为了更清晰地区分业务成果与用户成果。
核心洞见： 该画布就像一份保险单——在开始开发前暴露认知差距，确保你不会在错误的事情上浪费冲刺周期。

Canvas Structure (8 Boxes)

画布结构（8个模块）

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):
  1. Business Problem — What changed in the world that created a problem worth solving?
  2. Business Outcomes — What measurable behavior change indicates success?
  3. Users — Which persona(s) should you focus on first?
  4. User Outcomes & Benefits — Why would users seek this? What benefit do they gain?
  5. Solutions — What features/initiatives might solve the problem and meet user needs?
  6. Hypotheses — Testable assumptions combining boxes 2-5 (If/Then format)
  7. What's Most Important to Learn First? — The single riskiest assumption right now
  8. What's the Least Work to Learn Next? — Smallest experiment to validate/invalidate that assumption
布局（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个模块（按以下顺序填写）：
  1. 业务问题 — 世界发生了什么变化，导致出现了值得解决的问题？
  2. 业务成果 — 哪些可衡量的行为变化标志着成功？
  3. 用户 — 你首先应该聚焦哪类用户画像？
  4. 用户成果与收益 — 用户为何会寻求这个产品？他们能获得什么收益？
  5. 解决方案 — 哪些功能/举措可能解决问题并满足用户需求？
  6. 假设 — 结合模块2-5的可测试假设（采用「如果/那么」格式）
  7. 首先最需要了解什么？ — 当前风险最高的单个假设
  8. 验证下一个关键认知所需的最小工作量是什么？ — 用于验证/推翻该假设的最小实验

Why This Works

为何它有效

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.
以问题为核心，而非解决方案： 从「世界发生了什么变化？」而非「我们应该打造X」开始。这避免了以解决方案为导向的思维。
以假设为驱动： 在开发前明确假设。每个职能领域都暴露其风险（技术可行性、用户价值、商业可行性）。
以实验为重点： 在投入资源前验证假设。小型实验胜过大规模押注。
跨职能对齐： 共享画布创造了通用语言。每个人都能看到相同的认知差距。

Key Distinctions (Avoid Confusion)

关键区分（避免混淆）

Box 2 (Business Outcomes) vs. Box 4 (User Outcomes):
  • Box 2: Measurable behavior change (retention rate, time on site, average order value)
  • Box 4: Goals, benefits, emotions, empathy (save money, get promoted, spend time with family)
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.
模块2（业务成果）与模块4（用户成果）：
  • 模块2： 可衡量的行为变化（留存率、停留时长、平均订单价值）
  • 模块4： 目标、收益、情感、同理心（省钱、获得晋升、陪伴家人）
模块2是指标，模块4是人性。
解决方案（模块5）是假设，而非承诺： 列出候选解决方案（功能、政策，甚至商业模式转变）。你并非承诺全部打造——而是探索解决方案空间。
假设（模块6）必须可测试： 使用模板：「我们认为，如果[用户]通过[解决方案]获得[收益]，那么[业务成果]就能达成。」每个假设聚焦一个解决方案。

Anti-Patterns (What This Is NOT)

反模式（它不是什么）

  • Not a feature list: Solutions are ideas to test, not a backlog
  • Not a project plan: Canvas frames learning, not delivery timelines
  • Not a replacement for strategy: Canvas executes strategy; it doesn't create it
  • Not a one-time exercise: Re-visit as you learn; update assumptions
  • 不是功能列表： 解决方案是待测试的想法，而非待办事项
  • 不是项目计划： 画布聚焦学习，而非交付时间表
  • 不是战略的替代品： 画布执行战略，而非制定战略
  • 不是一次性练习： 随着学习不断回顾，更新假设

When to Use This

使用场景

✅ Use this when:
  • Starting a new product initiative or feature
  • Reframing an existing project (suspect you're building the wrong thing)
  • Aligning cross-functional teams on assumptions and experiments
  • Planning discovery sprints or MVPs
  • Stakeholders are solution-driven ("we need to build X") and you need to expose assumptions
❌ Don't use this when:
  • Problem and solution are already validated (move to execution)
  • Tactical bug fixes or technical debt (no learning needed)
  • Stakeholders have committed to a solution regardless of evidence (address alignment first)
✅ 适用于：
  • 启动新的产品举措或功能
  • 重构现有项目（怀疑正在打造错误的产品）
  • 让跨职能团队在假设和实验上达成共识
  • 规划发现冲刺或MVP
  • 利益相关者以解决方案为导向（「我们需要打造X」），而你需要暴露假设
❌ 不适用于：
  • 问题和解决方案已验证完成（进入执行阶段）
  • 战术性bug修复或技术债务（无需学习）
  • 利益相关者已承诺采用某解决方案，无论证据如何（先解决对齐问题）

Facilitation Source of Truth

协作执行参考标准

Use 
workshop-facilitation
 as the default interaction protocol for this skill.
It defines:
  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include 
    Other (specify)
    when useful)
This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
将
workshop-facilitation
作为此技能的默认交互协议。
它定义了：
  • 会议预告 + 参与模式（引导式、背景输出式、最佳猜测式）
  • 单轮一问制，使用通俗易懂的提示
  • 进度标签（例如，背景问题Qx/8和评分问题Qx/5）
  • 中断处理和暂停/恢复规则
  • 决策点的编号建议
  • 常规问题的快速选择编号响应选项（必要时包含「其他（请说明）」）
本文件定义了特定领域的评估内容。若存在冲突，遵循本文件的领域逻辑。

Application

应用

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.
使用
template.md
获取完整的可填写结构。
此交互式技能会按顺序引导你完成8个自适应问题（对应画布的每个模块）。在每个步骤中，Agent会提供指导、示例和选项，帮助你正确填写模块。

Step 0: Gather Context

步骤0：收集背景信息

Agent asks:
Before we fill out the Lean UX Canvas, let's gather context. Please share:
Business Context:
  • Stakeholder request, product brief, or initiative description
  • Business metrics (revenue, churn, growth targets, KPIs)
  • Strategic goals (OKRs, roadmap priorities)
User Context:
  • Customer research, personas, JTBD insights
  • User feedback, support tickets, churn reasons
  • Competitor analysis, market trends
You can paste:
  • PRD or product brief
  • Stakeholder memo
  • User research summary
  • Just describe the initiative briefly
Agent提问：
在填写Lean UX Canvas之前，我们先收集背景信息。请分享：
业务背景：
  • 利益相关者需求、产品简报或举措描述
  • 业务指标（收入、流失率、增长目标、KPI）
  • 战略目标（OKR、路线图优先级）
用户背景：
  • 客户研究、用户画像、JTBD洞察
  • 用户反馈、支持工单、流失原因
  • 竞品分析、市场趋势
你可以粘贴：
  • PRD或产品简报
  • 利益相关者备忘录
  • 用户研究摘要
  • 或简要描述该举措

Question 1: Business Problem (Box 1)

问题1：业务问题（模块1）

Agent asks:
What problem does the business have that you are trying to solve?
Describe:
  • Current state: How does the business deliver value today?
  • What changed: Market shift, competitive threat, customer behavior change, new delivery channel
  • Why it matters: Why isn't the current situation meeting expectations?
Good examples:
  • "Our checkout conversion rate dropped 15% after mobile traffic surpassed desktop. Our checkout flow wasn't designed for mobile, and competitors have one-tap checkout."
  • "Enterprise customers are churning after 6 months because our onboarding process requires 3+ weeks of manual configuration. Competitors offer self-service onboarding."
Bad examples (too vague):
  • "We need to increase revenue" (no context on what changed)
  • "Users want more features" (no business problem stated)
Agent offers 3 options:
  1. I'll describe the business problem — [Paste or write your description]
  2. Help me identify the business problem — [Agent asks follow-up questions: What changed? What metrics are affected? What are competitors doing?]
  3. I'm not sure what the business problem is — [Agent suggests starting with 
    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提问：
你试图解决的业务问题是什么？
请描述：
  • 当前状态： 企业当前如何交付价值？
  • 变化点： 市场转变、竞争威胁、用户行为变化、新交付渠道
  • 重要性： 为何当前情况未达预期？
优秀示例：
  • "移动流量超过桌面端后，我们的结账转化率下降了15%。我们的结账流程并非为移动端设计，而竞品已支持一键结账。"
  • "企业客户在6个月后流失，因为我们的入职流程需要3周以上的手动配置。竞品提供自助式入职。"
反面示例（过于模糊）：
  • "我们需要增加收入"（未说明变化背景）
  • "用户想要更多功能"（未提及业务问题）
Agent提供3个选项：
  1. 我来描述业务问题 — [粘贴或撰写你的描述]
  2. 帮我识别业务问题 — [Agent会追问：发生了什么变化？哪些指标受到影响？竞品在做什么？]
  3. 我不确定业务问题是什么 — [Agent建议先使用
    skills/problem-statement/SKILL.md
    或
    skills/problem-framing-canvas/SKILL.md
    ]
用户回复： [选择或描述]
Agent验证： 描述是否涵盖了变化点以及为何这会构成问题？若未涵盖，会提出澄清问题。

Question 2: Business Outcomes (Box 2)

问题2：业务成果（模块2）

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:
  • Increase mobile checkout conversion rate from 45% to 60%
  • Reduce enterprise onboarding time from 3 weeks to 3 days
  • Increase average order value from $50 to $75
  • Reduce customer support tickets by 30%
  • Increase free-to-paid conversion rate from 5% to 10%
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:
  1. I have specific metrics in mind — [State your business outcomes]
  2. Help me define measurable outcomes — [Agent suggests metrics based on the business problem]
  3. I only have lagging indicators (revenue, profit) — [Agent helps identify leading indicators that predict those outcomes]
User response: [Selection or description]
Agent validates: Are these measurable? Observable? Do they indicate behavior change (not just "increase revenue")?
Agent提问：
你如何判断已解决业务问题？会衡量哪些指标？
聚焦可衡量的行为变化（欢迎使用领先指标）。自问：「如果解决方案有效，人们的行为会有哪些不同？」
业务成果示例：
  • 将移动端结账转化率从45%提升至60%
  • 将企业入职时间从3周缩短至3天
  • 将平均订单价值从50美元提升至75美元
  • 将客户支持工单减少30%
  • 将免费版转付费版转化率从5%提升至10%
重要提示： 这是模块2（行为变化），而非模块4（用户收益/同理心）。指标放在这里，情感放在模块4。
Agent提供3个选项：
  1. 我有具体的指标 — [说明你的业务成果]
  2. 帮我定义可衡量的成果 — [Agent会根据业务问题建议指标]
  3. 我只有滞后指标（收入、利润） — [Agent会帮你识别能预测这些成果的领先指标]
用户回复： [选择或描述]
Agent验证： 这些指标是否可衡量、可观察？是否体现了行为变化（而非仅仅「增加收入」）？

Question 3: Users (Box 3)

问题3：用户（模块3）

Agent asks:
What types (i.e., personas) of users and customers should you focus on first?
Consider:
  • Who buys it?
  • Who uses it?
  • Who configures it?
  • Who administers it?
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:
  • "SMB owners (1-10 employees) in professional services (consultants, accountants, lawyers)"
  • "Enterprise IT admins who configure SSO for 500+ employees"
  • "Mobile-first millennials (25-35) who order takeout 3+ times per week"
Agent offers 3 options:
  1. I have personas already — [Reference 
    skills/proto-persona/SKILL.md
    or paste persona]
  2. Help me identify target users — [Agent asks: Who experiences the business problem most? Who's most likely to adopt? Who's easiest to reach?]
  3. I need to create personas first — [Agent suggests using 
    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提问：
你首先应该聚焦哪类（即用户画像）用户和客户？
考虑：
  • 谁购买产品？
  • 谁使用产品？
  • 谁配置产品？
  • 谁管理产品？
为何重要： 团队往往会在这里走捷径（「所有人」）。画布需要对用户的共同认知——而用户并不总是「客户」。
示例：
  • "专业服务领域（顾问、会计师、律师）的SMB所有者（员工1-10人）"
  • "为500+员工配置SSO的企业IT管理员"
  • "每周订购外卖3次以上的移动端优先千禧一代（25-35岁）"
Agent提供3个选项：
  1. 我已有用户画像 — [参考
    skills/proto-persona/SKILL.md
    或粘贴用户画像]
  2. 帮我识别目标用户 — [Agent会追问：谁受业务问题影响最大？谁最可能采用产品？谁最容易触达？]
  3. 我需要先创建用户画像 — [Agent建议使用
    skills/proto-persona/SKILL.md
    组件技能]
用户回复： [选择或描述]
Agent验证： 描述是否具体到能想象出真实用户？还是过于宽泛（「所有用户」）？

Question 4: User Outcomes & Benefits (Box 4)

问题4：用户成果与收益（模块4）

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:
  • Save 10 hours per week on manual data entry (spend more time with family)
  • Get promoted by delivering projects faster
  • Avoid embarrassment of failed checkout in front of friends
  • Feel confident configuring enterprise software without calling support
Why this matters: This is the empathy box. It's about human motivation, not just behavior change.
Agent offers 3 options:
  1. I know what users want to achieve — [Describe user benefits]
  2. Help me identify user benefits — [Agent prompts: What job are they hiring this product to do? What pain are they avoiding? What gain are they seeking?]
  3. I need to research this first — [Agent suggests 
    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提问：
用户为何会选择你的产品或服务？他们能获得什么收益？我们能观察到哪些行为变化，表明他们已达成目标？
聚焦目标、收益、情感、同理心——而非指标（指标放在模块2）。
用户成果与收益示例：
  • 每周节省10小时手动数据录入时间（多陪伴家人）
  • 通过更快交付项目获得晋升
  • 避免在朋友面前结账失败的尴尬
  • 无需致电支持即可自信地配置企业软件
为何重要： 这是同理心跳板。关乎人类动机，而非仅仅行为变化。
Agent提供3个选项：
  1. 我知道用户想要达成什么 — [描述用户收益]
  2. 帮我识别用户收益 — [Agent会提示：用户雇佣这个产品来完成什么任务？他们想避免什么痛苦？想获得什么收益？]
  3. 我需要先做调研 — [Agent建议使用
    skills/jobs-to-be-done/SKILL.md
    或
    skills/discovery-interview-prep/SKILL.md
    ]
用户回复： [选择或描述]
Agent验证： 描述是否解释了用户为何在意（而非仅仅他们会做什么）？

Question 5: Solutions (Box 5)

问题5：解决方案（模块5）

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:
  • One-tap mobile checkout (Apple Pay, Google Pay)
  • Self-service onboarding wizard (no human configuration)
  • AI-powered recommendation engine
  • Concierge onboarding (high-touch, manual—test before automating)
  • Change pricing model (usage-based instead of flat rate)
Important: These are hypotheses, not commitments. You're exploring options, not committing to build everything.
Agent offers 3 options:
  1. I have solution ideas — [List your candidate solutions]
  2. Help me brainstorm solutions — [Agent suggests solutions based on problem, outcomes, and users]
  3. I only have one solution in mind — [Agent challenges: "What else could solve this? What if that solution doesn't work?"]
User response: [Selection or description]
Agent validates: Do you have at least 3 candidate solutions? (More options = better hypotheses later)
Agent提问：
我们可以打造什么来解决业务问题，同时满足客户需求？
列出可能有效的功能、举措、政策、系统甚至商业模式转变。鼓励探索广泛的解决方案空间：大/小、创新、「奇特」以及非技术解决方案。
示例：
  • 移动端一键结账（Apple Pay、Google Pay）
  • 自助式入职向导（无需人工配置）
  • AI驱动的推荐引擎
  • concierge式入职（高接触、手动服务——在自动化前先测试）
  • 改变定价模式（从固定费率改为基于使用量）
重要提示： 这些是假设，而非承诺。你正在探索选项，而非承诺全部打造。
Agent提供3个选项：
  1. 我有解决方案想法 — [列出你的候选解决方案]
  2. 帮我头脑风暴解决方案 — [Agent会根据问题、成果和用户建议解决方案]
  3. 我只有一个解决方案想法 — [Agent会挑战：「还有什么能解决这个问题？如果这个解决方案无效怎么办？」]
用户回复： [选择或描述]
Agent验证： 你是否列出了至少3个候选解决方案？（选项越多，后续假设质量越高）

Question 6: Hypotheses (Box 6)

问题6：假设（模块6）

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:
  • Each hypothesis focuses on one solution (from Box 5)
  • Combines assumptions from Boxes 2, 3, 4, and 5
  • Must be testable (you can design an experiment to validate/invalidate it)
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):
  1. [Generated hypothesis 1]
  2. [Generated hypothesis 2]
  3. [Generated hypothesis 3]
Options:
  • Accept these hypotheses — [Agent records them]
  • Edit a hypothesis — [Modify wording]
  • Write my own hypotheses — [Use the template]
User response: [Selection or description]
Agent validates: Does each hypothesis clearly state what you believe will happen if the solution works?
Agent提问：
现在我们结合模块2-5的假设，创建可测试的假设。
使用此模板：
我们认为 [模块2的业务成果] 将在以下情况下达成： [模块3的用户] 通过 [模块5的解决方案] 获得 [模块4的收益]。
规则：
  • 每个假设聚焦一个解决方案（来自模块5）
  • 结合模块2、3、4和5的假设
  • 必须可测试（你可以设计实验来验证/推翻它）
示例：
我们认为 将移动端结账转化率从45%提升至60% 将在以下情况下达成： 移动端优先的千禧一代（25-35岁） 通过 一键Apple Pay集成 获得 更快捷、无摩擦的结账体验。
Agent提供：
根据你的输入，以下是建议的假设（对应模块5的每个解决方案）：
  1. [生成的假设1]
  2. [生成的假设2]
  3. [生成的假设3]
选项：
  • 接受这些假设 — [Agent记录假设]
  • 编辑某个假设 — [修改措辞]
  • 自行撰写假设 — [使用模板]
用户回复： [选择或描述]
Agent验证： 每个假设是否清晰说明了如果解决方案有效，你预期会发生什么？

Question 7: What's the Most Important Thing We Need to Learn First? (Box 7)

问题7：首先最需要了解什么？（模块7）

Agent asks:
For each hypothesis from Box 6, identify its riskiest assumptions. Then determine the riskiest one right now.
Types of risk:
  • Value risk: Will users actually use this? Do they care?
  • Usability risk: Can users figure out how to use it?
  • Feasibility risk: Can we technically build this?
  • Viability risk: Will this achieve the business outcome?
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:
  1. [Hypothesis 1 risk] — e.g., "Users will trust one-tap checkout without seeing itemized charges"
  2. [Hypothesis 2 risk] — e.g., "Self-service onboarding will reduce setup time to <3 days"
  3. [Hypothesis 3 risk] — e.g., "AI recommendations will increase average order value by 50%"
Which is the riskiest right now?
Options:
  1. Risk 1 — [Select and explain why]
  2. Risk 2 — [Select and explain why]
  3. Risk 3 — [Select and explain why]
  4. I'm not sure which is riskiest — [Agent helps prioritize: Which assumption, if wrong, would kill the initiative?]
User response: [Selection]
Agent records: This is the assumption we'll test first.
Agent提问：
针对模块6的每个假设，识别其风险最高的假设。然后确定当前风险最高的那个假设。
风险类型：
  • 价值风险： 用户真的会使用它吗？他们在意吗？
  • 可用性风险： 用户能弄明白如何使用它吗？
  • 可行性风险： 我们技术上能打造它吗？
  • 可行性风险： 这能达成业务成果吗？
提示： 在早期阶段，更多关注价值风险而非可行性（大多数情况下）。不要打造用户不需要的产品，即使技术上可行。
Agent提供：
根据你的假设，以下是风险最高的假设：
  1. [假设1的风险] — 例如，「用户会信任不显示明细的一键结账吗？」
  2. [假设2的风险] — 例如，「自助式入职能将设置时间缩短至<3天吗？」
  3. [假设3的风险] — 例如，「AI推荐能将平均订单价值提升50%吗？」
当前风险最高的是哪一个？
选项：
  1. 风险1 — [选择并说明原因]
  2. 风险2 — [选择并说明原因]
  3. 风险3 — [选择并说明原因]
  4. 我不确定哪个风险最高 — [Agent会帮助排序：哪个假设如果错误，会导致整个举措失败？]
用户回复： [选择]
Agent记录： 这是我们首先要测试的假设。

Question 8: What's the Least Amount of Work We Need to Do to Learn the Next Most Important Thing? (Box 8)

问题8：验证下一个关键认知所需的最小工作量是什么？（模块8）

Agent asks:
Design an experiment to validate or invalidate the riskiest assumption (from Box 7) as fast as you can.
Examples of experiment types:
  • Customer interviews — 5-10 interviews to test value hypothesis
  • Landing page — Fake door test to measure interest
  • Concierge / manual prototype — High-touch, manual version before automating
  • Wizard-of-Oz — Pretend the feature exists (humans behind the scenes)
  • Smoke test — Announce the feature, measure signups
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:
  1. Customer Interviews — Talk to 10 users, ask if they'd use [solution], observe their current workaround
  2. Landing Page Test — Create a landing page describing [solution], measure signup rate
  3. Concierge Test — Manually deliver [benefit] to 5 users, observe if they achieve [outcome]
  4. Wizard-of-Oz Prototype — Fake [solution] with humans behind the scenes, see if users complete the workflow
  5. Design a custom experiment — [Describe your experiment]
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提问：
设计一个实验，以最快速度验证或推翻风险最高的假设（来自模块7）。
实验类型示例：
  • 客户访谈 — 5-10次访谈，测试价值假设
  • 着陆页 — 假门测试，衡量兴趣
  • Concierge / 手动原型 — 高接触、手动版本，再自动化
  • 绿野仙踪原型 — 假装功能已存在（背后由人工操作）
  • 冒烟测试 — 宣布功能，衡量注册量
提醒： 实验设计是一门艺术。画布只是推动你去做这件事——你需要单独迭代实验设计。
Agent提供：
根据你风险最高的假设，以下是实验选项：
  1. 客户访谈 — 与10位用户交谈，询问他们是否会使用[解决方案]，观察他们当前的解决方法
  2. 着陆页测试 — 创建描述[解决方案]的着陆页，衡量注册率
  3. Concierge测试 — 手动为5位用户提供[收益]，观察他们是否达成[成果]
  4. 绿野仙踪原型 — 用人工操作模拟[解决方案]，观察用户是否能完成流程
  5. 设计自定义实验 — [描述你的实验]
你将运行哪个实验？
用户回复： [选择一个或描述自定义实验]
Agent验证： 这是能验证/推翻假设的最小测试吗？（如果耗时超过2周，那就太大了——拆分它）

Step 9: Review and Export Canvas

步骤9：回顾与导出画布

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:
  1. Run the experiment (Box 8) — Set a timeline (e.g., 2 weeks)
  2. Document learnings — What did you learn? Was the assumption validated or invalidated?
  3. Update the canvas — Revise hypotheses based on learnings, choose next riskiest assumption
  4. Iterate — Repeat Box 7 → Box 8 until confidence is high enough to build
Agent asks:
Would you like me to:
  1. Export this canvas as a Markdown file?
  2. Suggest related skills to use next (e.g., 
    skills/discovery-interview-prep/SKILL.md
    for customer interviews)?
  3. Refine a specific box (if something feels incomplete)?
Agent总结：
以下是你完成的Lean UX Canvas (v2)：
┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2)                                         │
│ 举措：[标题]                                                 │
│ 日期：[今日日期]                                             │
│ 迭代版本：1                                                  │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. 业务问题         │              │ 2. 业务成果           │
│ [你的输入]          │              │ [你的输入]            │
│                     │              │                       │
├─────────────────────┤ 5. 解决方案   ├───────────────────────┤
│ 3. 用户             │              │ 4. 用户成果与收益     │
│ [你的输入]          │ [你的输入]    │ [你的输入]            │
│                     │              │                       │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. 假设             │ 7. 首先需了解 │ 8. 实验               │
│ [你的输入]          │ [你的输入]    │ [你的输入]            │
│                     │              │                       │
└─────────────────────┴──────────────┴───────────────────────┘
后续步骤：
  1. 运行实验（模块8） — 设置时间线（例如，2周）
  2. 记录学习成果 — 你学到了什么？假设是否被验证/推翻？
  3. 更新画布 — 根据学习成果修订假设，选择下一个风险最高的假设
  4. 迭代 — 重复模块7 → 模块8，直到信心足够再投入开发
Agent提问：
你希望我：
  1. 将此画布导出为Markdown文件？
  2. 推荐后续相关技能（例如，用于客户访谈的
    skills/discovery-interview-prep/SKILL.md
    ）？
  3. 细化特定模块（如果某些内容不完整）？

Examples

示例

See 
examples/sample.md
for full Lean UX Canvas examples.
Mini example excerpt:
markdown
**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
查看
examples/sample.md
获取完整的Lean UX Canvas示例。
迷你示例节选：
markdown
**模块1：** 移动端结账转化率比桌面端低15%
**模块2：** 将移动端转化率从45%提升至60%
**模块8：** 一键结账的绿野仙踪测试

Common Pitfalls

常见陷阱

1. Starting with Solutions, Not Problems

1. 从解决方案开始，而非问题

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)?"
失败模式： 模块1写的是「我们需要打造X」，而非描述变化。
后果： 你打造了某人已经决定的解决方案，却未验证问题是否存在。
修复： 问自己：「世界发生了什么变化？为何现在这是个问题？」

2. Vague Business Outcomes

2. 模糊的业务成果

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%."
失败模式： 模块2写的是「增加收入」或「让用户开心」。
后果： 无法衡量成功；无法判断实验是否有效。
修复： 定义可衡量的行为变化。例如「将平均订单价值从50美元提升至75美元」或「将支持工单减少30%」。

3. Too-Broad User Segments

3. 过于宽泛的用户群体

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.
失败模式： 模块3写的是「所有用户」或「每个人」。
后果： 无法设计针对性实验；浪费时间在不会采用产品的用户画像上。
修复： 先选择一个用户画像。之后可以扩展。

4. Confusing Box 2 and Box 4

4. 混淆模块2和模块4

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).
失败模式： 将情感放在模块2，将指标放在模块4（反之亦然）。
后果： 假设不一致；成功标准不清晰。
修复： 模块2 = 行为变化（指标）。 模块4 = 目标、收益、情感（同理心）。

5. Only One Solution in Box 5

5. 模块5只有一个解决方案

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?"
失败模式： 只列出一个功能，因为利益相关者已经决定。
后果： 无法探索替代方案；无法测试哪个解决方案最佳。
修复： 强迫自己列出3+个解决方案。问自己：「还有什么能解决这个问题？」

6. Skipping Experiments (Box 8)

6. 跳过实验（模块8）

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.
失败模式：「我们直接打造，看看效果如何。」
后果： 浪费数周/数月打造错误的产品。
修复： 先设计最小的实验。如果想不到，可以使用
skills/pol-probe-advisor/SKILL.md
选择验证方法。

References

参考资料

Related Skills

相关技能

  • problem-statement (Component) — Frame problem before filling Box 1
  • problem-framing-canvas (Interactive) — MITRE Problem Framing before canvas
  • proto-persona (Component) — Create personas for Box 3
  • jobs-to-be-done (Component) — Identify user benefits for Box 4
  • epic-hypothesis (Component) — Write testable hypotheses (Box 6)
  • discovery-interview-prep (Interactive) — Design customer interviews for Box 8
  • pol-probe-advisor (Interactive) — Choose experiment type for Box 8
  • 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选择实验类型

External Frameworks

外部框架

  • Jeff Gothelf — Lean UX: Designing Great Products with Agile Teams (O'Reilly, 2013; 2nd ed. 2016)
  • Jeff Gothelf — Lean UX Canvas v2 (official blog post)
  • Lean UX Canvas PDF — Download v2 PDF
  • Jeff Gothelf — 《Lean UX: Designing Great Products with Agile Teams》（O'Reilly，2013；2016年第2版）
  • Jeff Gothelf — Lean UX Canvas v2（官方博客文章）
  • Lean UX Canvas PDF — 下载v2 PDF

Tools

工具

  • Miro / Mural — Digital whiteboard for collaborative canvas filling
  • Google Slides / PowerPoint — Template available from Jeff Gothelf's site
  • Notion / Coda — Database view for tracking multiple canvases
  • Miro / Mural — 用于协作填写画布的数字白板
  • Google Slides / PowerPoint — Jeff Gothelf官网提供模板
  • Notion / Coda — 用于跟踪多个画布的数据库视图