name: 用户故事映射工作坊 description: 通过询问关于系统、用户、工作流和优先级的自适应问题，指导产品经理创建用户故事映射—然后生成一个包含主干（活动）、用户任务和发布切片的二维地图。 type: 互动

目的

指导产品经理通过创建用户故事映射，询问自适应问题关于系统、用户、工作流和优先级—然后生成一个二维地图，包含主干（活动）、用户任务和发布切片。使用此方法从扁平的产品待办列表转向视觉故事映射，沟通大局，识别缺失功能，并实现有意义的发布规划—避免“上下文无关的杂项”，即故事失去与整体系统叙事的连接。

这不是一个待办列表生成器—它是一个视觉沟通框架，按用户工作流（水平）和优先级（垂直）组织工作。

关键概念

什么是用户故事映射？

故事映射（Jeff Patton）以两个维度组织用户故事：

水平轴（从左到右）： 活动按叙事/工作流顺序排列—就像向某人解释系统时的顺序

垂直轴（从上到下）： 每个活动内的优先级，最重要任务在顶部

结构：

主干（活动横跨顶部）
↓
用户任务（按优先级垂直下降）
↓
细节/验收标准（在底部）

关键原则

主干： 基本活动构成系统的结构核心—这些活动不相互优先排序；它们是叙事流。

行走骨架： 跨所有活动的最高优先级任务形成最小可行产品—最小的端到端功能。

肋骨： 支持任务垂直排列在每个活动下，通过位置表示优先级。

从左到右、从上到下的构建策略： 跨所有主要功能增量构建，而不是在开始另一个功能之前完全完成一个功能。

为什么这有效

视觉沟通： 故事映射作为信息辐射器保持展示，专注于大局
叙事结构： 按用户工作流组织，而非技术架构
发布规划： 水平切片揭示最小可行产品和增量发布
差距识别： 揭示扁平待办列表隐藏的缺失功能

反模式（这不是什么）

不是甘特图： 故事映射显示优先级，而非时间估计
不是技术架构： 映射遵循用户工作流，而非系统层（UI → API → DB）
不是项目计划： 它是发现和沟通工具，而非时间表

何时使用此技能

开始新产品或主要功能
重构现有待办列表（从扁平列表转向视觉映射）
对齐利益相关者范围和优先级
规划最小可行产品或增量发布

何时不使用此技能

单一功能项目（故事映射过度）
当待办列表已充分理解并优先排序时
技术重构工作（无用户工作流可映射）

促进真实来源

使用工作坊促进作为此技能的默认互动协议。

它定义：

会话提醒 + 进入模式（引导、上下文转储、最佳猜测）
单一问题回合，带简单语言提示
进度标签（例如，上下文 Qx/8 和评分 Qx/5）
中断处理和暂停/恢复行为
决策点带编号推荐
常规问题快速选择编号响应选项（在有用时包括其他（指定））

此文件定义特定领域的评估内容。如果有冲突，遵循此文件的领域逻辑。

应用

此互动技能询问最多 5 个自适应问题，在每个步骤提供3-4 个枚举选项。

使用template.md作为促进议程和输出检查清单。

互动模式：与skills/workshop-facilitation/SKILL.md配对，当您想要一步接一步流程，带决策点的编号推荐和常规问题的快速选择选项时。如果用户要求单次输出，跳过多回合促进。

步骤 0：收集上下文（提问前）

代理建议：

在创建您的故事映射之前，让我们收集上下文：

产品/功能上下文：

您映射什么系统或功能？
产品概念、PRD 草案或现有待办列表
网站副本、定位材料或用户流程
现有用户故事（如果从扁平待办列表过渡）

用户上下文：

目标人物角色或用户细分
用户研究、访谈或旅程映射
待完成工作或问题陈述

您可以直接粘贴此内容，或简要描述系统。

问题 1：定义范围

代理询问： “您映射什么？（范围是什么？）”

提供 4 个枚举选项：

整个产品 — “从发现到完成的完整端到端系统”（常用于新产品或全面重写）
主要功能区域 — “较大产品内的特定工作流（例如，‘入职’、‘结账’、‘报告’）”（常用于功能发布）
用户旅程 — “特定用户目标或待完成工作（例如，‘雇用承包商’、‘报税’）”（常用于 JTBD 驱动映射）
重新设计/重构 — “正在重建或简化的现有产品/功能”（常用于遗留系统现代化）

或描述您的特定范围。

用户响应： [选择或自定义]

问题 2：识别用户/人物角色

代理询问： “谁是此映射的主要用户？（列出人物角色或用户细分。）”

提供 4 个枚举选项：

单一人物角色 — “一种主要用户类型（例如，‘小企业主’）”（简化映射，适用于最小可行产品）
多个人物角色，共享工作流 — “不同用户类型，相同核心活动（例如，‘买家’和‘卖家’都浏览列表）”（常用于市场平台）
多个人物角色，不同工作流 — “具有不同工作流的不同用户类型（例如，‘管理员’与‘最终用户’）”（需要单独映射或泳道）
组织内角色 — “不同工作职能（例如，‘产品经理’、‘设计师’、‘工程师’）”（常用于内部工具）

或描述您的用户。

适配： 使用步骤 0 提供的上下文中的原型人物角色、JTBD 等

用户响应： [选择或自定义]

问题 3：生成主干（活动）

代理说： “让我们构建主干—用户执行以实现目标的活动的叙事流。”

代理生成 5-8 个活动，基于范围（问题 1）和用户（问题 2），按工作流顺序从左到右排列。

示例（如果范围 = “电子商务结账”）：

主干活动（从左到右）：

1. 浏览产品
2. 添加到购物车
3. 查看购物车
4. 输入配送信息
5. 输入支付信息
6. 确认订单
7. 接收确认

代理询问： “此主干是否捕捉完整工作流？我们应该添加、移除或重新排序活动吗？”

用户响应： [批准、修改或添加自定义活动]

问题 4：生成用户任务（在每个活动下）

代理说： “现在让我们在每个活动下添加用户任务，按优先级组织（顶部 = 必须拥有，底部 = 可拥有）。”

代理生成每个活动 3-5 个用户任务，按优先级垂直排列。

示例（对于活动 2：“添加到购物车”）：

添加到购物车（活动）
├─ 添加单一商品到购物车（必须拥有，行走骨架）
├─ 调整数量（必须拥有）
├─ 同时添加多个商品（应拥有）
├─ 保存商品稍后（可拥有）
└─ 添加礼品包装（可拥有）

代理重复所有主干活动，显示完整映射。

代理询问： “这捕捉关键任务吗？优先级正确吗（顶部 = 最小可行产品，底部 = 后续发布）？”

用户响应： [批准、修改或添加自定义任务]

问题 5：识别发布切片（行走骨架 + 增量）

代理说： “让我们通过在地图上绘制水平线来定义发布切片。”

代理生成 3 个发布切片：

发布 1（行走骨架）： 跨所有活动的最高优先级任务—最小端到端功能

发布 2（下一个增量）： 第二优先级任务，增强核心工作流

发布 3（优化/扩展）： 第三优先级任务（可拥有、边缘案例、优化）

示例：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发布 1（行走骨架）：
- 浏览产品（基本列表视图）
- 添加单一商品到购物车
- 查看购物车（行项目 + 总计）
- 输入配送信息（姓名、地址）
- 输入支付信息（仅信用卡）
- 确认订单（基本确认）
- 接收电子邮件确认
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发布 2（增强）：
- 产品过滤/搜索
- 在购物车中调整数量
- 保存稍后
- 多种配送选项
- 多种支付方式
- 订单跟踪链接
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发布 3（优化）：
- 产品推荐
- 访客结账
- 礼品包装
- 促销代码
- 高级支付选项
- 购买后调查
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

代理询问： “这些发布切片合理吗？我们应该调整范围或优先级吗？”

用户响应： [批准或修改]

输出：用户故事映射

完成流程后，代理输出：

# 用户故事映射：[问题 1 的范围]

**用户：** [来自问题 2]
**日期：** [今天的日期]

---

## 主干（活动）

[活动 1] → [活动 2] → [活动 3] → [活动 4] → [活动 5] → [活动 6]

---

## 完整故事映射

### [活动 1：名称]
- **[任务 1.1]** — 必须拥有（发布 1）
- **[任务 1.2]** — 应拥有（发布 2）
- **[任务 1.3]** — 可拥有（发布 3）

### [活动 2：名称]
- **[任务 2.1]** — 必须拥有（发布 1）
- **[任务 2.2]** — 应拥有（发布 2）
- **[任务 2.3]** — 可拥有（发布 3）

[...重复所有活动...]

---

## 发布切片

### 发布 1：行走骨架（最小可行产品）
**目标：** 最小端到端功能

**故事：**
- [任务 1.1] — [活动 1]
- [任务 2.1] — [活动 2]
- [任务 3.1] — [活动 3]
- [任务 4.1] — [活动 4]
- [任务 5.1] — [活动 5]
- [任务 6.1] — [活动 6]

**为什么这是行走骨架：** 提供具有每个活动最简单版本的完整工作流。

---

### 发布 2：增强功能
**目标：** 改进核心工作流，带优先级增强

**故事：**
- [任务 1.2] — [活动 1]
- [任务 2.2] — [活动 2]
- [任务 3.2] — [活动 3]
[...]

---

### 发布 3：优化与扩展
**目标：** 可拥有、边缘案例、优化

**故事：**
- [任务 1.3] — [活动 1]
- [任务 2.3] — [活动 2]
[...]

---

## 下一步

1. **细化故事：** 使用`skills/user-story/SKILL.md`编写带验收标准的详细故事
2. **估计工作量：** 评分故事（故事点、T恤尺码）
3. **与利益相关者验证：** 从左到右走查映射，确认优先级
4. **展示映射：** 打印/张贴为信息辐射器，供持续参考

---

**准备好写用户故事了吗？告诉我您是否想细化映射或分解特定故事。**

示例

示例 1：良好故事映射（电子商务结账）

问题 1 响应： “主要功能区域 — 电子商务结账工作流”

问题 2 响应： “单一人物角色 — 在线购物者”

问题 3 - 主干生成：

浏览 → 添加到购物车 → 查看购物车 → 输入配送 → 输入支付 → 确认 → 接收确认

问题 4 - 用户任务生成：

浏览产品
├─ 查看产品列表（发布 1）
├─ 搜索/过滤（发布 2）
└─ 产品推荐（发布 3）

添加到购物车
├─ 添加单一商品（发布 1）
├─ 调整数量（发布 2）
└─ 保存稍后（发布 3）

查看购物车
├─ 查看行项目 + 总计（发布 1）
├─ 应用促销代码（发布 2）
└─ 估计配送成本（发布 3）

[...等等...]

问题 5 - 发布切片：

发布 1： 行走骨架—基本流程，无额外功能
发布 2： 搜索、数量调整、促销代码
发布 3： 推荐、访客结账、礼品选项

为什么这有效：

主干遵循用户叙事（非技术层）
行走骨架提供端到端价值
增量发布添加复杂功能而不破坏核心流

示例 2：不良故事映射（技术层）

主干（错误）：

UI 层 → API 层 → 数据库层 → 部署

为什么这失败：

不以用户为中心（用户不关心技术架构）
无法增量提供端到端价值
瀑布思维伪装成故事映射

修复：

按用户工作流映射：“注册 → 配置设置 → 邀请团队 → 开始项目”
每个发布提供完整工作流，而非单一层

常见陷阱

陷阱 1：伪装扁平待办列表

症状： 故事映射只是垂直列表，无水平叙事

后果： 失去沟通益处；仍是“上下文无关杂项”

修复： 强制水平结构—活动横跨顶部，任务垂直下降

陷阱 2：技术架构作为主干

症状： 主干 = “前端 → 后端 → 数据库”

后果： 不以用户为中心，无法增量提供价值

修复： 主干应遵循用户工作流，而非系统层

陷阱 3：功能完整瀑布

症状： 发布 1 = “完全构建活动 1”，发布 2 = “完全构建活动 2”

后果： 所有活动完成前无端到端价值

修复： 行走骨架 = 跨所有活动的薄切片，增量增强

陷阱 4：过早过多细节

症状： 试图提前映射每个边缘案例和验收标准

后果： 分析瘫痪，失去大局

修复： 以主干 + 高级任务开始，后续细化

陷阱 5：映射隐藏于工具中

症状： 故事映射存在于 Jira/Miro，从未展示

后果： 失去信息辐射器价值

修复： 打印/张贴物理映射；使其对团队日常可见

参考资料

外部框架

Jeff Patton, User Story Mapping (2014) — 故事映射框架起源
Jeff Patton, “The New User Story Backlog is a Map” (博客) — 解释主干概念

Dean 的工作

[如果 Dean 有故事映射资源，链接此处]

来源

派生自skills/user-story/SKILL.md, skills/user-story-splitting/SKILL.md, 和skills/user-story-mapping/SKILL.md

技能类型： 互动 建议文件名： user-story-mapping-workshop.md 建议位置： /skills/interactive/ 依赖项： 使用skills/user-story-mapping/SKILL.md, skills/user-story/SKILL.md, skills/proto-persona/SKILL.md

用户故事映射工作坊Skill user-story-mapping-workshop