Back to Details

user-story-mapping

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

Visualize the user journey by creating a hierarchical map that breaks down high-level activities into steps and tasks, organized left-to-right as a narrative flow. Use this to build shared understanding across product, design, and engineering, prioritize features based on user workflows, and identify gaps or opportunities in the user experience.
This is not a backlog—it's a strategic artifact that shows how users accomplish their goals, which then informs what to build.
通过创建分层地图来可视化用户旅程，将高阶活动拆解为步骤和任务，按从左到右的叙事流进行组织。使用该方法在产品、设计和工程团队间建立共识，基于用户工作流确定功能优先级，并识别用户体验中的差距或机会。
这不是待办事项列表——它是一种战略工件，展示用户如何达成目标，进而指导团队应该构建什么。

Key Concepts

核心概念

The Jeff Patton Story Mapping Framework

Jeff Patton 用户故事地图框架

Invented by Jeff Patton, story mapping organizes work into a 2D structure:
Horizontal axis (left-to-right): User journey over time
  • Backbone: High-level activities the user performs
  • Steps: Specific actions within each activity
  • Tasks: Detailed work required to complete each step
Vertical axis (top-to-bottom): Priority and releases
  • Top rows: Essential tasks (MVP / Release 1)
  • Lower rows: Nice-to-have tasks (Future releases)
由Jeff Patton提出，故事地图将工作组织为二维结构：
横轴（从左到右）： 随时间推进的用户旅程
  • 主干： 用户执行的高阶活动
  • 步骤： 每个活动中的具体操作
  • 任务： 完成每个步骤所需的详细工作
纵轴（从上到下）： 优先级与版本发布
  • 顶部行： 核心任务（MVP / 第1版）
  • 下方行： 锦上添花的任务（未来版本）

Story Map Structure

故事地图结构

Segment → Persona → Narrative (User's goal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5]
     ↓              ↓              ↓              ↓              ↓
  [Step 1.1]     [Step 2.1]     [Step 3.1]     [Step 4.1]     [Step 5.1]
  [Step 1.2]     [Step 2.2]     [Step 3.2]     [Step 4.2]     [Step 5.2]
  [Step 1.3]     [Step 2.3]     [Step 3.3]     [Step 4.3]     [Step 5.3]
     ↓              ↓              ↓              ↓              ↓
  [Task 1.1.1]   [Task 2.1.1]   [Task 3.1.1]   [Task 4.1.1]   [Task 5.1.1]
  [Task 1.1.2]   [Task 2.1.2]   [Task 3.1.2]   [Task 4.1.2]   [Task 5.1.2]
  [Task 1.1.3]   [Task 2.1.3]   [Task 3.1.3]   [Task 4.1.3]   [Task 5.1.3]
  ...            ...            ...            ...            ...
Segment → Persona → Narrative (User's goal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5]
     ↓              ↓              ↓              ↓              ↓
  [Step 1.1]     [Step 2.1]     [Step 3.1]     [Step 4.1]     [Step 5.1]
  [Step 1.2]     [Step 2.2]     [Step 3.2]     [Step 4.2]     [Step 5.2]
  [Step 1.3]     [Step 2.3]     [Step 3.3]     [Step 4.3]     [Step 5.3]
     ↓              ↓              ↓              ↓              ↓
  [Task 1.1.1]   [Task 2.1.1]   [Task 3.1.1]   [Task 4.1.1]   [Task 5.1.1]
  [Task 1.1.2]   [Task 2.1.2]   [Task 3.1.2]   [Task 4.1.2]   [Task 5.1.2]
  [Task 1.1.3]   [Task 2.1.3]   [Task 3.1.3]   [Task 4.1.3]   [Task 5.1.3]
  ...            ...            ...            ...            ...

Why This Works

该方法的优势

  • User-centric: Organizes work around user goals, not engineering modules
  • Shared understanding: Product, design, engineering all see the same journey
  • Prioritization clarity: Top tasks = MVP, lower tasks = future iterations
  • Gap identification: Missing steps or tasks become obvious
  • Release planning: Draw horizontal "release lines" to define scope
  • 以用户为中心： 围绕用户目标而非工程模块组织工作
  • 共识建立： 产品、设计、工程团队看到的是同一旅程
  • 优先级清晰： 顶部任务=MVP，下方任务=未来迭代内容
  • 差距识别： 缺失的步骤或任务一目了然
  • 版本规划： 绘制横向"版本线"来定义范围

Anti-Patterns (What This Is NOT)

反模式（该方法不适用于以下场景）

  • Not a Gantt chart: This isn't project management—it's user journey visualization
  • Not a feature list: Activities aren't features—they're user behaviors
  • Not static: Story maps evolve as you learn more about users
  • 不是甘特图： 这不是项目管理工具——而是用户旅程可视化工具
  • 不是功能列表： 活动不是功能——而是用户行为
  • 并非静态： 故事地图会随着你对用户的了解加深而不断演进

When to Use This

适用场景

  • Kicking off a new product or major feature
  • Aligning stakeholders on user workflow
  • Prioritizing backlog based on user needs
  • Identifying MVP vs. future releases
  • Onboarding new team members to the product vision
  • 启动新产品或重大功能时
  • 让利益相关者对齐用户工作流时
  • 基于用户需求确定待办事项优先级时
  • 区分MVP与未来版本时
  • 向新团队成员介绍产品愿景时

When NOT to Use This

不适用场景

  • For trivial features (don't map what you already understand)
  • When user workflows are constantly changing (map stabilizes workflows)
  • As a replacement for user stories (the map informs stories, doesn't replace them)
  • 针对琐碎功能（无需映射已完全理解的内容）
  • 用户工作流频繁变化时（地图用于稳定工作流）
  • 替代用户故事（地图为故事提供信息，而非替代）

Application

应用步骤

Step 1: Define the Context

步骤1：定义上下文

Use 
template.md
for the full fill-in structure.
使用
template.md
获取完整的填空式结构。

Segment

用户细分

Who are you building for?
markdown
undefined
你为谁构建产品？
markdown
undefined

Segment:

细分用户群：

  • [Specify the target segment, e.g., "Small business owners using DIY accounting software"]

**Quality checks:**
- **Specific:** Not "users" but "enterprise IT admins" or "freelance designers"

---
  • [指定目标细分群体，例如："使用自助会计软件的小企业主"]

**质量检查：**
- **具体明确：** 不是"用户"，而是"企业IT管理员"或"自由设计师"

---

Persona

用户画像

Provide details about the persona within this segment (reference 
skills/proto-persona/SKILL.md
).
markdown
undefined
提供该细分群体内用户画像的详细信息（参考
skills/proto-persona/SKILL.md
）。
markdown
undefined

Persona:

用户画像：

  • [Describe the persona: demographics, behaviors, pains, goals]

**Example:**
- "Sarah, 35-year-old freelance graphic designer, manages 5-10 client projects at once, struggles with invoicing and payment tracking, wants to spend less time on admin and more time designing"

---
  • [描述用户画像：人口统计信息、行为、痛点、目标]

**示例：**
- "Sarah，35岁的自由平面设计师，同时管理5-10个客户项目，在发票和付款跟踪方面存在困难，希望减少行政工作时间，将更多时间用于设计"

---

Step 2: Define the Narrative

步骤2：定义叙事主线

What is the user trying to accomplish? Frame this as a Jobs-to-be-Done statement (reference 
skills/jobs-to-be-done/SKILL.md
).
markdown
undefined
用户想要达成什么目标？将其表述为Jobs-to-be-Done（待完成任务）陈述（参考
skills/jobs-to-be-done/SKILL.md
）。
markdown
undefined

Narrative:

叙事主线：

  • [Concise narrative of the persona's objective, e.g., "Complete a client project from kickoff to final payment"]

**Quality checks:**
- **Outcome-focused:** Not "use the product" but "deliver a client project on time and get paid"
- **One sentence:** If it takes more than one sentence, the scope may be too broad

---
  • [简明描述用户画像的目标，例如："完成从项目启动到最终收款的全流程客户项目"]

**质量检查：**
- **以结果为导向：** 不是"使用产品"，而是"按时交付客户项目并收到款项"
- **一句话表述：** 如果超过一句话，说明范围可能过于宽泛

---

Step 3: Identify Activities (Backbone)

步骤3：确定活动（主干）

List 3-5 high-level activities the persona engages in to fulfill the narrative. These form the backbone of your map.
markdown
undefined
列出用户画像为实现叙事主线而执行的3-5项高阶活动，这些将构成你的地图主干。
markdown
undefined

Activities:

活动：

  1. [Activity 1, e.g., "Negotiate project scope and pricing"]
  2. [Activity 2, e.g., "Execute design work"]
  3. [Activity 3, e.g., "Deliver final assets to client"]
  4. [Activity 4, e.g., "Send invoice and receive payment"]
  5. [Activity 5, optional]

**Quality checks:**
- **Sequential:** Activities happen in order (left-to-right)
- **User actions:** Describe what the user *does*, not what the product *provides*
- **3-5 activities:** Too few = oversimplified, too many = overwhelming

---
  1. [活动1，例如："协商项目范围与定价"]
  2. [活动2，例如："执行设计工作"]
  3. [活动3，例如："向客户交付最终成果"]
  4. [活动4，例如："发送发票并接收款项"]
  5. [活动5，可选]

**质量检查：**
- **按顺序排列：** 活动按时间顺序发生（从左到右）
- **用户行为：** 描述用户**做什么**，而非产品**提供什么**
- **3-5项活动：** 太少=过度简化，太多=过于繁杂

---

Step 4: Break Activities into Steps

步骤4：将活动拆解为步骤

For each activity, list 3-5 steps that detail how the activity is carried out.
markdown
undefined
为每个活动列出3-5个详细说明活动执行过程的步骤。
markdown
undefined

Steps:

步骤：

For Activity 1: [Activity Name]
  • Step 1: [Detail step 1, e.g., "Review client brief"]
  • Step 2: [Detail step 2, e.g., "Draft project proposal"]
  • Step 3: [Detail step 3, e.g., "Negotiate timeline and budget"]
  • Step 4: [Optional step 4]
  • Step 5: [Optional step 5]
For Activity 2: [Activity Name]
  • Step 1: [Detail step 1]
  • Step 2: [Detail step 2] ...

**Quality checks:**
- **Actionable:** Each step is something the user does
- **Observable:** You could watch someone perform this step
- **Logical sequence:** Steps follow a natural order

---
针对活动1：[活动名称]
  • 步骤1：[详细步骤1，例如："审阅客户简报"]
  • 步骤2：[详细步骤2，例如："草拟项目提案"]
  • 步骤3：[详细步骤3，例如："协商时间线与预算"]
  • 步骤4：[可选步骤4]
  • 步骤5：[可选步骤5]
针对活动2：[活动名称]
  • 步骤1：[详细步骤1]
  • 步骤2：[详细步骤2] ...

**质量检查：**
- **可执行：** 每个步骤都是用户实际会做的动作
- **可观察：** 你可以看到有人执行该步骤
- **逻辑连贯：** 步骤遵循自然顺序

---

Step 5: Break Steps into Tasks

步骤5：将步骤拆解为任务

For each step, list 5-7 tasks that must be completed.
markdown
undefined
为每个步骤列出5-7项必须完成的任务。
markdown
undefined

Tasks:

任务：

For Activity 1, Step 1: [Step Name]
  • Task 1: [Detail task 1, e.g., "Read client brief document"]
  • Task 2: [Detail task 2, e.g., "Identify key deliverables"]
  • Task 3: [Detail task 3, e.g., "Note budget constraints"]
  • Task 4: [Detail task 4, e.g., "Clarify timeline expectations"]
  • Task 5: [Detail task 5, e.g., "List open questions for client"]
  • Task 6: [Optional task 6]
  • Task 7: [Optional task 7]
For Activity 1, Step 2: [Step Name]
  • Task 1: [Detail task 1] ...

**Quality checks:**
- **Granular:** Tasks are small, specific actions
- **User-facing or behind-the-scenes:** Include both (e.g., "Send email" and "Receive confirmation")
- **Prioritizable:** You'll prioritize tasks vertically (top = essential, bottom = nice-to-have)

---
针对活动1，步骤1：[步骤名称]
  • 任务1：[详细任务1，例如："阅读客户简报文档"]
  • 任务2：[详细任务2，例如："识别关键交付成果"]
  • 任务3：[详细任务3，例如："记录预算限制"]
  • 任务4：[详细任务4，例如："明确时间线预期"]
  • 任务5：[详细任务5，例如："列出需向客户确认的问题"]
  • 任务6：[可选任务6]
  • 任务7：[可选任务7]
针对活动1，步骤2：[步骤名称]
  • 任务1：[详细任务1] ...

**质量检查：**
- **粒度精细：** 任务是具体的小型动作
- **覆盖用户端与后台：** 同时包含两者（例如："发送邮件"和"接收确认"）
- **可优先级排序：** 你将按纵向排列任务优先级（顶部=必备，底部=锦上添花）

---

Step 6: Prioritize Vertically

步骤6：纵向排序优先级

Arrange tasks top-to-bottom by priority:
  • Top rows: MVP / Release 1 (must-have)
  • Middle rows: Release 2 (important but not critical)
  • Bottom rows: Future / Nice-to-have
Draw horizontal "release lines" to demarcate scope.
按优先级从上到下排列任务：
  • 顶部行： MVP / 第1版（必备功能）
  • 中间行： 第2版（重要但非关键）
  • 底部行： 未来版本 / 锦上添花功能
绘制横向"版本线"来划分范围。

Step 7: Identify Gaps and Opportunities

步骤7：识别差距与机会

Review the map and ask:
  • Are there missing steps or tasks?
  • Are there pain points we're not addressing?
  • Are there opportunities to delight users?
  • Do all activities flow logically?
审阅地图并思考：
  • 是否存在缺失的步骤或任务？
  • 是否有我们未解决的痛点？
  • 是否有取悦用户的机会？
  • 所有活动的流程是否符合逻辑？

Examples

示例

See 
examples/sample.md
for a full story map example.
查看
examples/sample.md
获取完整的故事地图示例。

Common Pitfalls

常见陷阱

Pitfall 1: Activities Are Features, Not User Behaviors

陷阱1：活动是功能而非用户行为

Symptom: "Activity 1: Use the dashboard. Activity 2: Generate reports."
Consequence: You've mapped the product, not the user journey.
Fix: Reframe as user actions: "Activity 1: Monitor project progress. Activity 2: Summarize work for stakeholders."
症状： "活动1：使用仪表盘。活动2：生成报告。"
后果： 你映射的是产品，而非用户旅程。
解决方法： 重构为用户行为："活动1：监控项目进度。活动2：为利益相关者总结工作成果。"

Pitfall 2: Too Many Activities

陷阱2：活动数量过多

Symptom: 10+ activities across the backbone
Consequence: Map becomes overwhelming and loses focus.
Fix: Consolidate. If you have 10 activities, you're likely mixing activities with steps. Aim for 3-5 high-level activities.
症状： 主干上有10+项活动
后果： 地图变得过于繁杂，失去焦点。
解决方法： 合并活动。如果有10项活动，你可能混淆了活动与步骤。目标是3-5项高阶活动。

Pitfall 3: Tasks Are Too Vague

陷阱3：任务过于模糊

Symptom: "Task 1: Do the thing"
Consequence: Can't prioritize or estimate vague tasks.
Fix: Be specific: "Task 1: Enter client email address in the 'Bill To' field."
症状： "任务1：做这件事"
后果： 无法对模糊的任务进行优先级排序或估算。
解决方法： 具体化："任务1：在'收款方'字段中输入客户邮箱地址。"

Pitfall 4: Ignoring Vertical Prioritization

陷阱4：忽略纵向优先级排序

Symptom: All tasks at the same level—no MVP vs. future releases defined
Consequence: No clarity on what to build first.
Fix: Explicitly prioritize. Draw release lines. Force hard choices about what's MVP.
症状： 所有任务处于同一层级——未定义MVP与未来版本
后果： 无法明确首先构建什么。
解决方法： 明确划分优先级。绘制版本线。强制决定哪些是MVP必备功能。

Pitfall 5: Mapping in Isolation

陷阱5：孤立制作地图

Symptom: PM creates the map alone, then presents it to the team
Consequence: No shared ownership or understanding.
Fix: Map collaboratively. Run a story mapping workshop with product, design, and engineering.
症状： 产品经理独自制作地图，然后向团队展示
后果： 团队没有共同的所有权或共识。
解决方法： 协作制作地图。与产品、设计和工程团队一起举办故事地图工作坊。

References

参考资料

Related Skills

相关技能

  • skills/proto-persona/SKILL.md
    — Defines the persona for the story map
  • skills/jobs-to-be-done/SKILL.md
    — Informs the narrative and activities
  • skills/user-story/SKILL.md
    — Tasks from the map become user stories
  • skills/problem-statement/SKILL.md
    — Problem statement frames the narrative
  • skills/proto-persona/SKILL.md
    — 为故事地图定义用户画像
  • skills/jobs-to-be-done/SKILL.md
    — 为叙事和活动提供信息
  • skills/user-story/SKILL.md
    — 地图中的任务可转化为用户故事
  • skills/problem-statement/SKILL.md
    — 问题陈述为叙事奠定框架

External Frameworks

外部框架

  • Jeff Patton, User Story Mapping (2014) — Origin of the story mapping technique
  • Teresa Torres, Continuous Discovery Habits (2021) — Opportunity solution trees (complementary to story maps)
  • Jeff Patton, User Story Mapping (2014) — 故事映射技术的起源
  • Teresa Torres, Continuous Discovery Habits (2021) — 机会解决方案树（与故事地图互补）

Dean's Work

Dean的工作

  • User Story Mapping Prompt (adapted from Jeff Patton's methodology)
  • User Story Mapping Prompt（改编自Jeff Patton的方法论）

Provenance

来源

  • Adapted from 
    prompts/user-story-mapping.md
    in the 
    https://github.com/deanpeters/product-manager-prompts
    repo.
Skill type: Component Suggested filename: 
user-story-mapping.md
Suggested placement: 
/skills/components/
Dependencies: References 
skills/proto-persona/SKILL.md
, 
skills/jobs-to-be-done/SKILL.md
, 
skills/user-story/SKILL.md
, 
skills/problem-statement/SKILL.md
  • 改编自
    https://github.com/deanpeters/product-manager-prompts
    仓库中的
    prompts/user-story-mapping.md
技能类型： 组件 建议文件名： 
user-story-mapping.md
建议存放位置： 
/skills/components/
依赖项： 参考
skills/proto-persona/SKILL.md
, 
skills/jobs-to-be-done/SKILL.md
, 
skills/user-story/SKILL.md
, 
skills/problem-statement/SKILL.md