目的

通过构建层级化地图，将高层级活动逐层拆解为步骤与任务，并按从左到右的叙事流进行组织，从而可视化用户旅程。该地图用于在产品、设计与工程团队之间建立共识，基于用户工作流对功能进行优先级排序，并识别用户体验中的缺口或机会。

这不是一份待办事项清单（backlog）——而是一项战略型产物，它揭示用户 如何 达成目标，进而指导我们决定 构建什么。

核心概念

Jeff Patton 故事地图框架

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

水平轴（从左到右）： 用户随时间演进的旅程

• 主干（Backbone）： 用户执行的高层级活动
• 步骤（Steps）： 每个活动中涉及的具体动作
• 任务（Tasks）： 完成每个步骤所需的具体工作

垂直轴（从上到下）： 优先级与发布规划

• 顶部行： 必需任务（MVP / Release 1）
• 底部行： 可选任务（未来版本）

故事地图结构

细分群体 → 用户画像 → 叙事（用户目标）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[活动 1] → [活动 2] → [活动 3] → [活动 4] → [活动 5]
     ↓              ↓              ↓              ↓              ↓
  [步骤 1.1]     [步骤 2.1]     [步骤 3.1]     [步骤 4.1]     [步骤 5.1]
  [步骤 1.2]     [步骤 2.2]     [步骤 3.2]     [步骤 4.2]     [步骤 5.2]
  [步骤 1.3]     [步骤 2.3]     [步骤 3.3]     [步骤 4.3]     [步骤 5.3]
     ↓              ↓              ↓              ↓              ↓
  [任务 1.1.1]   [任务 2.1.1]   [任务 3.1.1]   [任务 4.1.1]   [任务 5.1.1]
  [任务 1.1.2]   [任务 2.1.2]   [任务 3.1.2]   [任务 4.1.2]   [任务 5.1.2]
  [任务 1.1.3]   [任务 2.1.3]   [任务 3.1.3]   [任务 4.1.3]   [任务 5.1.3]
  ...            ...            ...            ...            ...

为何有效

• 以用户为中心： 围绕用户目标组织工作，而非工程模块
• 共享理解： 产品、设计、工程团队看到的是同一套用户旅程
• 优先级清晰： 顶部任务 = MVP，底部任务 = 后续迭代
• 缺口识别： 缺失的步骤或任务一目了然
• 发布规划： 绘制水平方向的“发布线”以界定范围

反模式（这不是什么）

• 不是甘特图（Gantt chart）： 这并非项目管理工具，而是用户旅程可视化手段
• 不是功能列表： 活动 ≠ 功能，而是用户行为
• 不是静态文档： 随着对用户的认知加深，故事地图持续演进

适用场景

• 启动新产品或重大功能时
• 协调各利益相关方对用户工作流的理解时
• 依据用户需求对 backlog 进行优先级排序时
• 界定 MVP 与后续版本范围时
• 向新团队成员传达产品愿景时

不适用场景

• 针对微小功能（无需映射你已充分理解的内容）
• 当用户工作流持续变动时（故事地图适用于稳定的工作流）
• 作为用户故事（user stories）的替代品（地图用于启发用户故事，而非取代之）

应用方法

步骤 1：定义上下文

使用 template.md 获取完整填空式结构。

细分群体（Segment）

你正在为谁构建产品？

### Segment:
- [明确目标群体，例如：“使用 DIY 会计软件的小型企业主”]

质量检查：

• 具体明确： 不是泛泛而谈的“用户”，而是“企业 IT 管理员”或“自由职业设计师”

用户画像（Persona）

提供该细分群体内典型用户的详细信息（参考 skills/proto-persona/SKILL.md）。

### Persona:
- [描述用户画像：人口统计特征、行为模式、痛点、目标]

示例：

• “Sarah，35 岁，自由职业平面设计师，同时管理 5–10 个客户项目，苦恼于开票与付款追踪，希望减少行政事务耗时，将更多精力投入设计工作。”

步骤 2：定义叙事（Narrative）

用户试图完成什么？请以“待完成的工作（Jobs-to-be-Done）”句式表述（参考 skills/jobs-to-be-done/SKILL.md）。

### Narrative:
- [简明扼要地陈述用户画像的目标，例如：“从项目启动到最终收款，完整交付一个客户项目”]

质量检查：

• 聚焦结果： 不是“使用产品”，而是“按时交付客户项目并收到付款”
• 单句表达： 若需超过一句话，则范围可能过宽

步骤 3：识别活动（Backbone）

列出用户为实现该叙事所开展的 3–5 个高层级活动。这些构成地图的主干。

### Activities:
1. [活动 1，例如：“协商项目范围与报价”]
2. [活动 2，例如：“执行设计工作”]
3. [活动 3，例如：“向客户交付最终资产”]
4. [活动 4，例如：“开具发票并收取款项”]
5. [活动 5，可选]

质量检查：

• 顺序性： 活动按时间先后顺序排列（从左到右）
• 用户行为： 描述用户 做什么，而非产品 提供什么
• 数量适中（3–5 个）： 过少则过于简化，过多则令人难以聚焦

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

针对每个活动，列出 3–5 个步骤，详述该活动如何展开。

### Steps:

**For Activity 1: [Activity Name]**
- Step 1: [步骤 1 细节，例如：“审阅客户需求文档”]
- Step 2: [步骤 2 细节，例如：“草拟项目提案”]
- Step 3: [步骤 3 细节，例如：“协商时间表与预算”]
- Step 4: [可选步骤 4]
- Step 5: [可选步骤 5]

**For Activity 2: [Activity Name]**
- Step 1: [步骤 1 细节]
- Step 2: [步骤 2 细节]
...

质量检查：

• 可操作性： 每个步骤均为用户实际执行的动作
• 可观测性： 你可以直观观察某人执行该步骤
• 逻辑顺序： 步骤遵循自然流程

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

针对每个步骤，列出 5–7 项必须完成的具体任务。

### Tasks:

**For Activity 1, Step 1: [Step Name]**
- Task 1: [任务 1 细节，例如：“阅读客户需求文档”]
- Task 2: [任务 2 细节，例如：“识别关键交付物”]
- Task 3: [任务 3 细节，例如：“标注预算限制”]
- Task 4: [任务 4 细节，例如：“明确时间节点预期”]
- Task 5: [任务 5 细节，例如：“列出需向客户确认的问题”]
- Task 6: [可选任务 6]
- Task 7: [可选任务 7]

**For Activity 1, Step 2: [Step Name]**
- Task 1: [任务 1 细节]
...

质量检查：

• 颗粒度细： 任务应为小而具体的动作
• 兼顾前台与后台： 同时包含用户可见操作与后台流程（例如：“发送邮件”和“接收确认回执”）
• 可优先级排序： 你将在垂直方向上对任务排序（顶部 = 必须实现，底部 = 可选）

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

按优先级自上而下排列任务：

• 顶部行： MVP / Release 1（必须实现）
• 中部行： Release 2（重要但非紧急）
• 底部行： 未来版本 / 可选功能

绘制水平方向的“发布线”，以明确各发布版本的范围边界。

步骤 7：识别缺口与机会

通览整张地图，提出以下问题：

• 是否存在缺失的步骤或任务？
• 是否存在尚未解决的用户痛点？
• 是否存在提升用户惊喜感的机会？
• 所有活动是否逻辑连贯、顺畅流转？

示例

参见 examples/sample.md 查看完整的故事地图示例。

常见陷阱

陷阱 1：将活动误当作功能，而非用户行为

表现： “活动 1：使用仪表盘。活动 2：生成报表。”

后果： 你映射的是产品本身，而非用户旅程。

修正方式： 重述为用户行为：“活动 1：监控项目进度。活动 2：向利益相关方汇总工作成果。”

陷阱 2：活动数量过多

表现： 主干线上罗列了 10 项以上活动

后果： 地图变得庞杂难懂，失去焦点。

修正方式： 合并精简。若出现 10 项活动，很可能混淆了“活动”与“步骤”。目标应为 3–5 个高层级活动。

陷阱 3：任务描述过于笼统

表现： “任务 1：做这件事”

后果： 笼统的任务无法评估优先级，亦难以估算工作量。

修正方式： 明确具体：“任务 1：在‘账单地址（Bill To）’字段中输入客户邮箱地址。”

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

表现： 所有任务处于同一层级，未界定 MVP 与后续版本

后果： 无法明确应优先构建哪些内容。

修正方式： 显式设定优先级；绘制发布线；强制做出关于 MVP 范围的艰难取舍。

陷阱 5：孤立地绘制地图

表现： 产品经理独自完成地图后，再向团队展示

后果： 缺乏共同所有权与深层理解。

修正方式： 协作式绘制。联合产品、设计与工程团队开展故事地图工作坊。

参考资料

外部框架

• Jeff Patton，《User Story Mapping》（2014）—— 故事地图技术的起源
• Teresa Torres，《Continuous Discovery Habits》（2021）—— 机会解决方案树（Opportunity Solution Trees），与故事地图互补