需求列表最大的问题是看不出用户能不能把事情做完。一个按优先级排序的 Backlog，前二十条可能全是"搜索优化"相关，做完之后用户能搜到东西了，但还是没法下单——因为下单相关的需求都排在第三十位以后。
用户故事地图解决的就是这件事：横轴按用户完成任务的顺序排列，纵轴按优先级排列。横着切一刀，切出来的就是一个用户能走通完整流程的可发布版本。
一、三层结构
从上到下三层，含义逐级细化：
| 层级 | 是什么 | 举例（在线购物） | 数量 |
|---|---|---|---|
| 用户活动 | 用户要完成的大目标 | 找商品、下单、收货、售后 | 4–8 个 |
| 用户任务 | 达成目标的具体步骤 | 搜索、筛选、看详情、比价 | 每个活动 3–8 个 |
| 用户故事 | 支撑任务的具体功能 | 按价格排序、看历史价格曲线 | 每个任务若干 |
第一层和第二层构成"骨干"（Backbone），它描述的是用户完整的任务流，横向从左到右按时间顺序排列。这一层画对了，后面的排列才有意义。
第三层是"肉"，纵向排列，越靠上越重要。
二、搭建的四个步骤
第一步：定用户和范围。 和其他产品图一样，先明确是谁的故事地图。多角色产品建议每个核心角色画一张，或者用不同颜色区分。
第二步：铺骨干。 把用户活动横向排开，再在每个活动下面横向排出任务。这一步最好用便签在画布上做——因为顺序会反复调整。
判断骨干对不对的方法：从左到右念一遍，能不能念成一句通顺的话？"用户先找商品，然后下单，然后等收货，有问题再售后"——通顺，说明骨干成立。
第三步：往下挂故事。 每个任务下面，把能想到的功能都写成便签挂上去。这一步鼓励发散，先不管做不做得完。
第四步：纵向排序。 每一列内部按重要性从上到下排。最上面的是"没有它这个任务就完不成"的功能。
三、怎么切版本
这是故事地图最有价值的用法。横着划一条线，线以上的就是这个版本的范围。
第一条线（第一个可发布版本）的判断标准：这条线以上的功能，能让用户把整条任务流从头走到尾吗？
- 能走通，哪怕每一步都很简陋 → 这是一个合格的 MVP
- 走不通，某个环节是空白 → 必须把那一列最上面的故事拉上来
这就是故事地图和普通 Backlog 的核心差别：它强制你保证每个版本都是"能用的产品"，而不是"一堆功能的集合"。
第二条线、第三条线依此类推，每条线之间的部分是下一个版本的增强。
四、四个常见错误
错误一：骨干按功能模块排。 横轴变成了"用户模块、商品模块、订单模块"，这是产品结构不是任务流。检查方法就是前面说的"能不能念成通顺的话"。
错误二：只画理想路径。 只有成功下单的流程，没有"没找到想要的""支付失败""想改地址"这些分支。真实用户大量时间花在这些路径上。
错误三：故事写成了功能规格。 "商品列表页支持按价格、销量、上新三个维度排序，默认按综合排序"——这是规格说明，不是用户故事。用户故事应该是"我想快速找到便宜的选项"。
错误四：画完就转成 Backlog 然后扔掉。 故事地图的价值在于持续提供全局视角。转成 Backlog 之后，开发过程中随时可以回到地图上看"我们现在做到哪一列了"。
五、什么场景最适合用
不是所有情况都需要故事地图。三种情况用它收益最大：
新产品从零规划。 需求还没成形，需要先想清楚用户完整的任务流。
版本范围争不下来。 各方都觉得自己的需求最重要，铺成地图后"这一列是空的，用户走不下去"是最有力的论据。
跨团队对齐。 产品、设计、研发看同一张地图，讨论范围时指的是同一件事。
反过来，单点功能优化、Bug 修复、技术债处理，用普通的需求列表更合适，不必强行铺地图。
六、和需求池、看板怎么配合
三样东西的分工：
- 故事地图——回答"整体规划是什么、这个版本做到哪"
- 需求池——回答"还有哪些候选需求"
- 看板——回答"当前谁在做什么、卡在哪"
推荐的流转方式：新需求先进需求池 → 评审时放到故事地图上对应的位置（看它补强哪个任务）→ 确定进入版本后拆成任务卡进看板。
把这三样放在同一块画布上，流转过程是可见的——需求从池子里被拖到地图上，再被拖进看板，每一步的判断依据都留在原地。
英飞·思想家的画布支持便签、看板、导图等多种组件同屏组合，故事地图用便签铺、看板用看板组件，两者并排放，实时协作时不同角色可以同时操作。
七、工作坊怎么组织
故事地图通常不是一个人画出来的，而是团队共创的产物。一个可复用的工作坊流程：
- 开场对齐（10 分钟）——说清楚用户是谁、这次要规划的范围
- 个人发散（15 分钟）——每人独立写用户任务的便签，不讨论
- 铺骨干（30 分钟）——一起把便签排成任务流，合并重复的
- 挂故事（30 分钟）——分组往下挂功能便签
- 纵向排序（20 分钟）——每列内部排优先级，有分歧的当场讨论
- 切版本（20 分钟）——画线，确认每条线以上都能走通
远程做这个工作坊的关键是所有人看到同一处。画布上的视野跟随功能可以让主持人带着大家看当前讨论的那一列，不用反复说"看左边第三列"。
常见问题
用户故事地图和需求列表有什么区别？
需求列表是一维的优先级排序，看不出用户能否完成完整任务；故事地图是二维的，横轴保证流程完整，纵轴保证优先级合理。
一张地图画多少个用户活动？
4–8 个。太少说明范围划得过窄，太多建议按用户角色或产品线拆成多张。
多角色产品怎么画？
每个核心角色画一张，或者在同一张图上用不同颜色的便签区分。角色之间有交接时，交接点要明确标出来。
故事地图和用户旅程图有什么关系？
旅程图关注用户的体验和情绪，用于发现问题；故事地图关注功能规划和版本切分，用于安排工作。通常先做旅程图找问题，再用故事地图规划怎么解决。
画完之后怎么维护？
建议保留在画布上，开发过程中标注每一列的完成状态，作为持续的全局视图，而不是转成 Backlog 后就废弃。
结语
用户故事地图的核心价值是保证每个版本都是能用的产品。横轴的任务流保证完整性，纵轴的优先级保证效率，横切一刀就是一个版本——这个机制比任何优先级公式都直接。
铺骨干时记得念一遍是否通顺，切版本时记得检查有没有空列。配合用户旅程图一起用，从发现问题到规划解决方案就串起来了。