user-story-mapping

目的

通过创建分层地图，将高层级活动拆解为步骤和任务，并按从左到右的叙事流程进行组织，从而可视化用户旅程。借此在产品、设计和工程团队之间建立共识，根据用户工作流确定功能优先级，并发现用户体验中的缺口或机会。

这不是待办事项列表，而是一份战略性产物，用于展示用户如何实现目标，并以此指导我们构建什么。

核心概念

Jeff Patton 故事地图框架

故事地图由 Jeff Patton 创立，将工作组织为二维结构：

横轴（从左到右）： 随时间展开的用户旅程

• 主干： 用户执行的高层级活动
• 步骤： 每项活动中的具体操作
• 任务： 完成每个步骤所需的详细工作

纵轴（从上到下）： 优先级和版本发布

• 顶部行： 必要任务（MVP / 第 1 版）
• 底部行： 可有可无的任务（未来版本）

故事地图结构

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]
  ...            ...            ...            ...            ...

这种方式为何有效

• 以用户为中心： 围绕用户目标组织工作，而不是围绕工程模块
• 建立共识： 产品、设计和工程团队都能看到相同的用户旅程
• 明确优先级： 顶部任务 = MVP，底部任务 = 未来迭代
• 发现缺口： 缺失的步骤或任务一目了然
• 规划发布： 绘制水平的“版本发布线”来定义范围

反模式（这不是什么）

• 不是甘特图： 这不是项目管理工具，而是用户旅程可视化
• 不是功能列表： 活动不是功能，而是用户行为
• 不是静态的： 随着对用户了解加深，故事地图也会不断演进

适用场景

• 启动新产品或重大功能
• 让利益相关者就用户工作流达成共识
• 根据用户需求确定待办事项的优先级
• 区分 MVP 和未来版本
• 帮助新团队成员了解产品愿景

不适用场景

• 对于无关紧要的功能（不要映射你已经了解的内容）
• 用户工作流不断变化时（地图有助于稳定工作流）
• 作为用户故事的替代品（地图为用户故事提供参考，但不会取代它们）

---

应用

步骤 1：定义背景

使用 template.md 获取完整的填写结构。

用户细分

你要为谁构建产品？

### Segment:
- [Specify the target segment, e.g., "Small business owners using DIY accounting software"]

质量检查：

• 具体： 不要写“用户”，而要写“企业 IT 管理员”或“自由职业设计师”

---

用户画像

提供此细分群体中用户画像的详细信息（参考 skills/proto-persona/SKILL.md）。

### Persona:
- [Describe the persona: demographics, behaviors, pains, goals]

示例：

• “Sarah，35 岁的自由职业平面设计师，同时管理 5-10 个客户项目，苦于处理发票和付款追踪，希望减少行政事务上的时间，把更多时间用于设计”

---

步骤 2：定义叙事

用户想要完成什么？将其表述为待完成任务（Jobs-to-be-Done）陈述（参考 skills/jobs-to-be-done/SKILL.md）。

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

质量检查：

• 聚焦结果： 不要写“使用产品”，而要写“按时交付客户项目并获得报酬”
• 一句话： 如果需要超过一句话，范围可能过于宽泛

---

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

列出用户画像为实现叙事目标所参与的 3-5 项高层级活动。这些活动构成地图的主干。

### 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]

质量检查：

• 有先后顺序： 活动按顺序发生（从左到右）
• 用户行为： 描述用户做什么，而不是产品提供什么
• 3-5 项活动： 太少会过于简化，太多则会令人不知所措

---

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

对于每项活动，列出 3-5 个步骤，详细说明如何执行该活动。

### 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]
...

质量检查：

• 可执行： 每个步骤都是用户会执行的操作
• 可观察： 你可以观察某人执行这一步骤
• 逻辑顺序： 步骤按自然顺序排列

---

第 5 步：将步骤拆分为任务

为每个步骤列出 5-7 个必须完成的任务。

### 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]
...

质量检查：

• 细致具体： 任务应是小而明确的行动
• 面向用户或幕后： 两者都要包含（例如“发送电子邮件”和“收到确认”）
• 可排序优先级： 你将按垂直方向对任务排序（顶部 = 必需，底部 = 锦上添花）

---

第 6 步：按垂直方向排序优先级

按优先级从上到下排列任务：

• 顶部行： MVP / 第 1 版（必需）
• 中间行： 第 2 版（重要但非关键）
• 底部行： 未来 / 锦上添花

绘制水平“版本分界线”以划定范围。

---

第 7 步：找出缺口和机会

检查故事地图并思考：

• 是否遗漏了步骤或任务？
• 是否有我们尚未解决的痛点？
• 是否有让用户惊喜的机会？
• 所有活动的流程是否合理？

---

示例

查看 examples/sample.md，了解完整的故事地图示例。

---

常见陷阱

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

症状：“活动 1：使用仪表板。活动 2：生成报告。”

**后果：**你绘制的是产品，而非用户旅程。

**解决方法：**改为描述用户行动：“活动 1：监控项目进度。活动 2：向利益相关者总结工作。”

---

陷阱 2：活动太多

**症状：**主干上有 10 个以上的活动

**后果：**地图变得过于复杂，失去重点。

**解决方法：**合并活动。如果有 10 个活动，你很可能把活动和步骤混在了一起。目标是设置 3-5 个高层级活动。

---

陷阱 3：任务过于模糊

症状：“任务 1：做那件事”

**后果：**无法对模糊的任务排序优先级或估算工作量。

**解决方法：**具体描述：“任务 1：在‘账单寄送至’字段中输入客户电子邮件地址。”

---

陷阱 4：忽略垂直优先级排序

**症状：**所有任务都处于同一层级——没有明确区分 MVP 和未来版本

**后果：**无法明确应先构建什么。

**解决方法：**明确排序优先级。绘制版本分界线。果断确定 MVP 的范围。

---

陷阱 5：独自绘制地图

**症状：**项目经理独自创建地图，然后展示给团队

**后果：**团队缺乏共同的归属感和理解。

**解决方法：**协作绘制地图。与产品、设计和工程团队一起开展故事地图工作坊。

---

参考资料

外部框架

• Jeff Patton，《User Story Mapping》（2014）——故事地图技术的起源
• Teresa Torres，《Continuous Discovery Habits》（2021）——机会解决方案树（可与故事地图搭配使用）