用户故事地图把用户完成一件事的活动横向展开，再把每个活动的细节和变化放在下方。它最有价值的用途，是检查首个版本能否让用户从头到尾完成任务，而不是仅仅做完几个功能模块。
可以用墨刀白板整理用户故事地图：先放活动骨架，再补步骤和变化，最后标出版本切片。不要一上来就把需求池里的所有便签倒进画布；那只会得到一张更宽的待办列表。
为什么按模块排列的清单看不见断点
假设团队做培训报名系统，需求池按“账号、课程、订单、通知”分组。完成账号和课程模块，看起来已有一半进度，但用户仍可能不能报名，也不知道报名后怎样参加。模块完成度和任务完成度不是同一件事。
故事地图从学员视角讲一条完整故事：找到课程、确认是否适合、报名、得到确认、参加课程、获取课后资料。地图横轴主要表达活动顺序，不是时间排期；下方则容纳不同情况、细节和候选方案。
Jeff Patton对故事地图的介绍强调围绕用户做什么组织讨论。它能帮助团队看见整体体验，但不会自动决定优先级；投入、风险和业务目标仍需要判断。
先锁定一个角色和一个目标
本例先只画“学员报名并参加一门课程”。课程管理员、讲师和财务的工作另设地图，必要时用交接点连接。如果把所有角色的操作放成同一条横轴，很快就会混淆谁在执行什么。
地图顶部写清起点和终点：学员从得知有课程开始，到完成参加并找到课后资料结束。目标不是“使用培训系统”，因为这个说法无法判断什么时候完成。范围暂不包括课程编排、讲师结算等后台工作，但相关依赖要在对应节点旁提示。
用动词建立活动骨架
先放五个高层活动：“寻找课程—判断是否适合—提交报名—参加课程—获取资料”。再讲一遍故事，检查是否缺少确认结果、时间地点或进入课堂的环节。不要急着追求每列便签数量一样多。
| 高层活动 | 具体步骤 | 可能的变化 |
|---|---|---|
| 寻找课程 | 浏览列表，按日期筛选 | 没有合适场次，稍后再看 |
| 判断是否适合 | 查看目标、时间、准备要求 | 资格不满足，课程已满 |
| 提交报名 | 填写资料，确认场次，查看结果 | 修改信息，名额发生变化 |
| 参加课程 | 查看地点或入口，确认参加 | 时间调整，临时取消 |
| 获取资料 | 找到课后内容，下载或查看 | 资料尚未提供，无访问权限 |
表中的内容用于说明拆解方式，实际项目应替换成研究和业务资料。故事地图不是凭想象填满所有分支的竞赛；暂时不清楚的地方可以标记待确认，留出讨论空间。
首版切片要横着穿过完整任务
如果第一版只做“精美课程列表”和“完善账号中心”，学员仍然无法完成报名。更有意义的切片可能是：能浏览少量课程，读懂适用条件，提交基本报名，得到确认，并找到参加入口。每个环节都不一定功能丰富，但整条路径能成立。
在地图上画一条发布边界，将首版必须具备的任务放在上方，后续增强项放在下方。把“智能推荐”“个性化课程收藏”“多语言资料”等放到后续，并不代表它们不重要，而是需要先证明当前目标是否必须依赖它们。
切片不能只是把每列最上面的便签机械连起来。提交报名如果依赖资格校验，确认页如果依赖课程名额，相关条件也要进入当前切片。必要的异常路径同样不能全留到下一版，否则所谓“端到端”只存在于理想演示中。
每个取舍都问“去掉以后任务还能完成吗”
讨论某个功能是否进入首版时，先问它保护的是哪个用户结果。如果删除收藏功能，用户还能直接报名，那么收藏可能是体验增强；如果删除报名结果确认，用户无法知道是否占到名额，它就是路径中的必要环节。
还有一种情况：某项能力可以由人工临时完成。比如首版课程只有三场，工作人员可以维护课程资料，但这需要明确负责人、容量和失误处理，不能用“先人工”掩盖无人承接的环节。地图旁应写出人工交接点，后续再决定何时自动化。
把取舍理由记成短句：“支持目标A”“解决风险B”“依赖C尚未准备好”。不要只写高、中、低，否则一周后团队很难理解当初为什么把它放在某条发布线下面。
一次讨论可以按这个顺序进行：先由熟悉用户的一人讲完整个任务，其他人只补遗漏；再把存在分歧的活动用不同标记暂存，不急着评估实现；随后共同选一条可完成任务的最小路径；最后请研发指出依赖和风险，回头修正切片。这样的顺序能避免会议一开始就被某个组件或接口的实现细节带走。
如果团队对某项用户行为没有资料，便签应写“待验证：学员从哪里寻找课后资料”，不要写成确定需求“新增资料中心”。两者看似只差几个字，却会让团队接下来分别去做研究或直接开发。地图可以容纳未知，版本承诺则需要先处理会影响完成路径的未知。
地图上的便签怎样进入研发任务
地图决定故事之间的关系，单条用户故事则需要继续写清角色、目标与验收条件。比如“确认报名”可以展开为：学员提交后能看到报名状态、场次和记录编号；名额发生变化时不能显示成功；重新进入时可以找到已提交记录。
需要把便签写成可评审的单条故事，可参考用户故事与验收标准的写法。地图不必复制每条故事的全部字段，只需要有稳定编号和关联位置，让修改能回到整体上下文。
任务拆到研发排期以后，也不应把地图丢掉。新约束出现时，检查它影响哪些活动和版本边界；评审原型时，沿当前切片走完整个任务，而不是按画布顺序演示孤立页面。
故事地图、旅程图和路线图各自回答什么
| 表达方式 | 核心问题 | 常见产物 |
|---|---|---|
| 用户故事地图 | 任务由哪些活动组成，版本先完成哪一条路径 | 活动骨架、细节与切片 |
| 用户旅程图 | 用户跨触点经历了什么，哪里产生困难 | 行为、触点、情绪与机会 |
| 产品路线图 | 团队接下来围绕什么目标投入 | 目标、方向、阶段与沟通视图 |
一张地图可以和产品Roadmap关联，但不要把横向活动顺序当成月份。故事地图的收获不是多了一张图，而是团队能指着首版边界回答：用户将怎样完成任务，哪里仍有断点，哪些增强值得留待以后。
