用户故事地图的可参考示例，通常由一条按用户活动从左到右展开的主干、按优先级从上到下排列的故事卡片，以及贯穿全图的发布切分线组成。下面给出一份已填写的完整示例——“在线课程报名与学习”，逐项解释主干、活动、任务、故事和切分线的填写方式，并总结可迁移到其他业务场景的规律与适用边界。示例为演示情景，用于说明方法，不代表真实客户案例。
要点总览（TL;DR）
- 一份可参考的用户故事地图示例由横向主干（浏览课程—报名付费—开始学习—完成与评价）、纵向按优先级排列的故事卡片和两条发布切分线组成。
- 示例中首版四张故事卡片串成“看到课程—下单—进入学习—看到进度”的最小闭环，第一条切分线据此划定，第二版放体验增强，后续版本放扩展场景。
- 首次绘制可按四步走：从用户目标反推主干、先铺广度再定深度、用切分线对应版本规划、逐项检查后做一次跨角色评审。
- 故事地图适合需求梳理、版本规划和跨角色对齐，不替代系统架构设计、UI 绘制和需求内容的分析澄清。
- 地图绘制后，故事卡片需作为工作项按层级录入并按版本切分，评审与验收通过状态流转记录，避免地图与实际排期脱节。
示例目标：这张故事地图要回答什么
假设一个六人产品团队正在开发面向职场学习者的在线课程产品，成员包括产品经理、设计师、两名开发、一名测试和一名运营。团队此前用需求列表排期，讨论时经常出现“这个功能属于哪一段用户旅程”“首版到底交付到哪一步”的争论。这次他们决定首次绘制用户故事地图，把用户从接触课程到完成学习的全过程铺开，再决定先做哪一段。
这张地图要回答三个具体问题：第一，用户完成一次课程学习会经历哪些连续活动，团队对旅程的理解是否一致；第二，首版应该覆盖哪几段活动，哪些故事必须进入首版才能让用户走通一条完整路径；第三，剩余故事如何分批进入后续版本，避免首版范围失控。
需要说明的是，以下内容是为讲解方法而构造的演示情景，课程名称、活动划分和版本安排均为示例设定。团队在实际绘制时，应替换为自己产品的用户目标和业务约束，地图的结论也会随之变化。
完整示例：在线课程报名与学习故事地图
下面这张表就是已填写的示例地图。横向主干按用户完成学习的先后顺序展开为四段活动：浏览课程、报名付费、开始学习、完成与评价。纵向每个活动下先列任务，再列具体故事卡片，并按优先级从上到下排列。两条切分线把地图分成三个发布批次：第一条切分线以上为首版范围，两条切分线之间为第二版，其余为后续版本。
| 层级 | 浏览课程 | 报名付费 | 开始学习 | 完成与评价 |
|---|---|---|---|---|
| 用户目标 | 找到适合的课程 | 顺利完成购买 | 按计划学完内容 | 确认收获并反馈 |
| 任务 | 查看课程列表；查看课程详情；比较课程 | 选择班期；提交订单；完成支付 | 进入课程；观看课时；记录进度 | 完成全部课时；提交评价；获取证书 |
| 故事（首版，切分线一以上） | 作为学习者，我能按分类浏览课程列表，看到课程名称、讲师和价格 | 作为学习者，我能选择班期并提交订单，看到应付金额 | 作为学习者，我能进入已购课程并播放第一节课时 | 作为学习者，我能看到课程完成进度百分比 |
| 故事（第二版，两条切分线之间） | 作为学习者，我能按关键词搜索课程，并按评分排序 | 作为学习者，我能用优惠码支付并收到订单确认 | 作为学习者，我能标记课时完成，下次从断点继续 | 作为学习者，我能提交星级评价和文字反馈 |
| 故事（后续版本，切分线二以下） | 作为学习者，我能收藏课程并接收开课提醒 | 作为学习者，我能申请发票并查看历史订单 | 作为学习者，我能下载课时资料离线观看 | 作为学习者，我能获得结业证书并分享到社交平台 |
这张表的关键在于读法：横着看是一条完整的用户旅程，任何一列空缺都意味着该段活动在对应版本中走不通；竖着看是同一段活动在不同版本中的深度递进。首版四张故事卡片合起来，能让一名学习者完成“看到课程—下单—进入学习—看到进度”的最小闭环，这就是第一条切分线的划分依据。
逐项解释：主干、活动、任务与故事怎么填
主干与用户活动
主干是地图最上方的一行，用用户视角的动词短语描述旅程阶段。示例中的“浏览课程—报名付费—开始学习—完成与评价”按时间顺序排列，每一段都以用户动作开头，而不是以系统模块命名。这样填写的依据是：主干要能让非技术角色读懂用户如何一步步达成目标。如果写成“课程管理—订单管理—学习管理”，地图就退化成了功能清单，横向的旅程感会丢失。
任务层与故事层的区分
任务层描述用户在某段活动中要完成的动作，粒度比活动细、比故事粗，例如“查看课程详情”“提交订单”。故事层则是可以独立开发、独立验收的最小交付单元，写成“作为某类用户，我能做某动作，以便获得某结果”的句式。示例中“作为学习者，我能选择班期并提交订单，看到应付金额”就是一条故事，它对应任务“提交订单”，但增加了角色、动作结果和可观察的界面反馈。区分这两层的实际意义在于：任务帮助团队对齐旅程理解，故事才是进入排期和开发的对象。
故事卡片的写法与验收要点
示例中的故事卡片遵循三个填写要点。角色写具体，用“首次购课的学习者”比笼统的“用户”更能暴露差异需求；动作写用户能完成的事，而不是系统内部实现；结果写用户可观察到的反馈，例如“看到应付金额”“看到完成进度百分比”。验收要点可以直接从故事的结果部分派生：应付金额是否正确显示、进度百分比是否随课时完成更新。这样写出的卡片在评审时能快速判断是否可测。
发布切分线的划分依据
切分线是横贯地图的横线，用来标记版本边界。示例中第一条切分线依据“最小可走通闭环”划定：四段活动各保留一张最基础的故事，保证用户能完成一次完整学习流程。第二条切分线依据“体验增强”划定：搜索排序、优惠码、断点续播、评价反馈属于让流程更顺畅的能力，放在第二版。剩余故事涉及收藏提醒、发票、离线下载和证书分享，属于扩展场景，进入后续版本。划分时优先保证每段活动都有故事入选，避免某个版本出现旅程断点。
可迁移规律：换一个业务场景怎么套用
把上面的示例迁移到自己的业务，可以按以下步骤操作，每一步都有明确的产物和完成标志。
- 从用户目标反推主干。先写下目标用户是谁、他要达成什么结果，再把达成过程拆成五到七个连续活动，用动词短语命名。完成标志是：团队成员能指着主干复述一遍用户旅程，且对活动顺序没有分歧。
- 先铺广度，再定深度。在每个活动下先列任务，确保横向每一段都有内容，再挑选每个任务下最基础的故事填入首版。完成标志是：首版故事能串成一条从进入到完成的完整路径。
- 用切分线对应版本规划。先画第一条线确定最小闭环，再画第二条线区分体验增强与扩展场景。每条线都要能回答“这个版本交付后，用户能走到哪一步”。完成标志是：每个版本都有清晰的范围说明，且没有版本出现旅程断点。
- 首次绘制时逐项检查。检查活动是否以用户动作命名、故事是否包含角色与可观察结果、切分线是否覆盖每段活动、是否有故事缺少验收要点。完成标志是：地图经过一次跨角色评审，产品、设计、开发和运营对首版范围达成一致。
这套步骤的适用条件是团队已经对目标用户有基本共识。如果用户群体尚未明确，应先补充用户研究，再绘制地图，否则主干的活动划分容易变成团队内部想象的产物。
适用边界：示例能覆盖与不能覆盖的部分
故事地图示例适合三类场景：需求梳理时把零散需求放回用户旅程中判断轻重；版本规划时用切分线明确每个批次的范围；跨角色对齐时用一张图让产品、设计、开发和运营讨论同一件事。示例中的表格结构本身也可以作为团队首次绘制时的参照格式。
它不能替代的内容同样需要明确。故事地图不承担系统架构设计，示例中的故事卡片不涉及服务拆分、数据模型或接口设计；它也不是 UI 绘制工具，卡片上的界面反馈只用于说明验收要点，不构成视觉稿；地图更不能替代需求内容的分析与澄清，故事是否值得做、业务规则如何定义，仍需在需求评审中单独判断。
示例规模与团队实际规模存在差异。本文示例只有四段活动和十余张卡片，适合小团队快速对齐；业务链条更长、角色更多的产品，主干活动可能扩展到十余段，故事数量成倍增加，此时需要按角色或场景拆成多张地图，避免单张图过于拥挤。地图也不是一次绘制的静态文档，当用户目标、版本节奏或业务规则变化时，切分线和故事优先级需要同步维护，否则地图会与实际排期脱节。
把示例地图落到协作工具中的管理动作
地图绘制完成后，真正的管理动作才刚开始。示例中的每张故事卡片需要作为可跟踪的工作项录入系统，并按“活动—任务—故事”的层级组织，这样团队在排期和查看进度时仍能保持与地图一致的视角。第一条和第二条切分线对应版本或迭代的规划边界，首版故事进入当前迭代，第二版故事进入待规划池，后续版本故事保留在积压列表中，避免范围混淆。
在评审与交接环节，故事卡片需要携带状态流转：从待评审到已确认，再到开发中、待验收和已完成。示例中“提交订单并看到应付金额”这类故事，在评审时补充验收要点，开发完成后由测试按要点核验，状态随之更新。ONES 可以承载这一流程：故事卡片作为工作项录入并支持父子层级，切分线对应的版本在版本计划中管理，评审与验收通过状态流转记录交接结果。团队由此在地图之外获得一份与之一致、可跟踪的工作项清单，地图负责表达旅程与优先级，工具负责承载执行与状态。
常见问题
团队第一次画故事地图，主干活动应该拆到多细？
示例中主干拆为四段活动，每段以用户动作命名，粒度以“团队能指着主干复述一遍用户旅程且对顺序没有分歧”为准。首次绘制建议控制在五到七段，过细会让地图变成任务清单，过粗则无法暴露旅程断点。如果业务链条较长，可以按角色或场景拆成多张地图，而不是把单张图的主干无限拉长。
故事卡片和任务有什么区别，排期时应该用哪一层？
任务层描述用户在某段活动中的动作，如“提交订单”，用于对齐旅程理解；故事层是可独立开发、独立验收的最小交付单元，写成“作为某类用户，我能做某动作，以便获得某结果”。排期和开发的对象是故事卡片，任务层保留在地图上帮助团队看清活动全貌。示例中“选择班期并提交订单，看到应付金额”就是由任务派生出的故事。
发布切分线画几条合适，依据是什么？
示例画了两条切分线，分成三个批次。第一条依据“最小可走通闭环”划定，保证每段活动至少有一张基础故事，用户能完成一次完整流程；第二条依据“体验增强”划定，把搜索排序、优惠码、断点续播、评价反馈放入第二版；其余扩展场景进入后续版本。切分线数量取决于版本节奏，关键是每条线都能回答“这个版本交付后用户能走到哪一步”，且不出现旅程断点。
示例里的故事卡片可以直接套用到我们自己的产品吗？
示例是演示情景，课程名称、活动划分和版本安排均为讲解方法而设定，不能直接当作自己产品的需求清单。可迁移的是结构与写法：主干用用户动作命名、故事包含具体角色和可观察结果、切分线优先保证每段活动都有故事入选。套用时需要替换为目标用户和业务约束，并补充验收要点，故事是否值得做、业务规则如何定义仍需在需求评审中单独判断。
地图画完之后，怎么保证它和实际排期不脱节？
把每张故事卡片作为可跟踪的工作项按“活动—任务—故事”层级录入，切分线对应版本或迭代的规划边界，首版故事进入当前迭代，后续故事保留在待规划池。评审与验收通过状态流转记录，例如从待评审到已确认、开发中、待验收和已完成。当用户目标或版本节奏变化时，同步调整切分线和故事优先级，地图才能持续反映实际排期。
