名称：用户故事映射 描述：通过创建分层地图来可视化用户旅程，将高级活动分解为步骤和任务，组织成从左到右的叙事流。使用这个来构建产品、设计和工程之间的共享理解，基于用户工作流优先处理功能，并识别用户体验中的差距或机会。 类型：组件
目的
通过创建分层地图来可视化用户旅程，将高级活动分解为步骤和任务，组织成从左到右的叙事流。使用这个来构建产品、设计和工程之间的共享理解，基于用户工作流优先处理功能，并识别用户体验中的差距或机会。
这不是一个待办事项列表——它是一个战略工件，显示用户如何实现他们的目标，从而指导构建什么。
关键概念
Jeff Patton的故事映射框架
由Jeff Patton发明，故事映射将工作组织成2D结构：
水平轴（从左到右）： 用户随时间推移的旅程
- 主干： 用户执行的高级活动
- 步骤： 每个活动中的具体行动
- 任务： 完成每个步骤所需的详细工作
垂直轴（从上到下）： 优先级和发布
- 顶部行： 基本任务（MVP / 发布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，底部任务 = 未来迭代
- 差距识别： 缺失的步骤或任务变得明显
- 发布规划： 绘制水平“发布线”来定义范围
反模式（这不是什么）
- 不是甘特图： 这不是项目管理——它是用户旅程可视化
- 不是功能列表： 活动不是功能——它们是用户行为
- 不是静态的： 故事映射随着对用户了解更多而演变
何时使用这个
- 启动新产品或主要功能时
- 对齐利益相关者关于用户工作流时
- 基于用户需求优先处理待办事项时
- 识别MVP与未来发布时
- 向新团队成员介绍产品愿景时
何时不使用这个
- 对于琐碎功能（不要映射你已经理解的内容）
- 当用户工作流不断变化时（映射稳定工作流）
- 作为用户故事的替代品（映射指导故事，但不替换它们）
应用
步骤1：定义上下文
使用 template.md 获取完整的填充结构。
细分
你为谁构建？
### 细分：
- [指定目标细分，例如，“使用DIY会计软件的小企业主”]
质量检查：
- 具体： 不是“用户”，而是“企业IT管理员”或“自由设计师”
人物画像
提供此细分内人物画像的详细信息（参考 skills/proto-persona/SKILL.md）。
### 人物画像：
- [描述人物画像：人口统计、行为、痛点、目标]
示例：
- “Sarah，35岁自由平面设计师，同时管理5-10个客户项目，在发票和付款跟踪方面挣扎，希望减少在管理上的时间，更多时间设计”
步骤2：定义叙事
用户试图完成什么？ 以此作为Jobs-to-be-Done语句（参考 skills/jobs-to-be-done/SKILL.md）。
### 叙事：
- [人物画像目标的简明叙事，例如，“从启动到最终付款完成客户项目”]
质量检查：
- 结果导向： 不是“使用产品”，而是“按时交付客户项目并获得付款”
- 一句话： 如果超过一句话，范围可能太广
步骤3：识别活动（主干）
列出3-5个高级活动，人物画像参与以实现叙事。这些形成映射的主干。
### 活动：
1. [活动1，例如，“协商项目范围和定价”]
2. [活动2，例如，“执行设计工作”]
3. [活动3，例如，“向客户交付最终资产”]
4. [活动4，例如，“发送发票并接收付款”]
5. [活动5，可选]
质量检查：
- 顺序： 活动按顺序发生（从左到右）
- 用户行动： 描述用户做什么，而不是产品提供什么
- 3-5个活动： 太少 = 过于简化，太多 = 令人不知所措
步骤4：将活动分解为步骤
对于每个活动，列出3-5个步骤，详细说明如何执行活动。
### 步骤：
**对于活动1：[活动名称]**
- 步骤1：[详细步骤1，例如，“审查客户简报”]
- 步骤2：[详细步骤2，例如，“起草项目提案”]
- 步骤3：[详细步骤3，例如，“协商时间线和预算”]
- 步骤4：[可选步骤4]
- 步骤5：[可选步骤5]
**对于活动2：[活动名称]**
- 步骤1：[详细步骤1]
- 步骤2：[详细步骤2]
...
质量检查：
- 可操作： 每个步骤是用户做的某事
- 可观察： 你可以观看某人执行此步骤
- 逻辑顺序： 步骤遵循自然顺序
步骤5：将步骤分解为任务
对于每个步骤，列出5-7个必须完成的任务。
### 任务：
**对于活动1，步骤1：[步骤名称]**
- 任务1：[详细任务1，例如，“阅读客户简报文档”]
- 任务2：[详细任务2，例如，“识别关键交付物”]
- 任务3：[详细任务3，例如，“注意预算限制”]
- 任务4：[详细任务4，例如，“澄清时间线期望”]
- 任务5：[详细任务5，例如，“列出对客户的开放问题”]
- 任务6：[可选任务6]
- 任务7：[可选任务7]
**对于活动1，步骤2：[步骤名称]**
- 任务1：[详细任务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：孤立映射
症状： 产品经理独自创建映射，然后呈现给团队
后果： 没有共享所有权或理解。
修复： 协作映射。与产品、设计和工程一起运行故事映射研讨会。
参考
相关技能
skills/proto-persona/SKILL.md— 为故事映射定义人物画像skills/jobs-to-be-done/SKILL.md— 指导叙事和活动skills/user-story/SKILL.md— 映射中的任务成为用户故事skills/problem-statement/SKILL.md— 问题陈述框架叙事
外部框架
- Jeff Patton, 用户故事映射 (2014) — 故事映射技术的起源
- Teresa Torres, 持续发现习惯 (2021) — 机会解决方案树（与故事映射互补）
Dean的工作
- 用户故事映射提示（改编自Jeff Patton的方法论）
出处
- 改编自
prompts/user-story-mapping.md在https://github.com/deanpeters/product-manager-prompts仓库。
技能类型： 组件
建议文件名： 用户故事映射.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