需求池里堆满需求，产品却越来越难用？用户故事地图帮你从用户视角重构需求管理。本文详解其定义、用法与避坑指南，助你打造真正完整的产品体验。

做产品经理，或多或少都经历过这种场面：

需求池里密密麻麻躺着几十上百条需求。

业务说这个功能很急，领导说那个能力很重要，研发还在追问上个和上上个版本遗留的技术债什么时候处理。

每条需求单独看，好像都有道理。

但把它们放在一起，就很难说清楚。这些需求到底在解决谁的问题？用户完成一件事的完整过程是什么？这一版做完以后，产品究竟能不能真正用起来？

咱就是说，需求确实越来越多了，至于产品有没有越来越完整，那就不一定了。

以前我也会觉得，需求管理无非就是把需求来源、优先级、负责人和迭代时间记录清楚。

后来做的项目越来越复杂，踩的坑越来越多，就知道，需求清单只能帮我们管理一条条需求，却很难帮我们看见用户完成一件事的全过程。

而用户故事地图，恰好解决的是这个问题。

一、用户故事地图到底是什么？

先不讲那些复杂定义。

说人话就是：把用户为了完成一个目标需要做的事情，按照先后顺序铺在一张图上。

比如，我们要设计一个员工报销系统。

如果按照传统的功能清单去拆，可能会拆成：

• 报销单管理
• 发票管理
• 审批管理
• 财务管理
• 消息通知
• 数据统计

看起来很完整，也很像那么回事。

但问题是，这些都是系统功能，不是用户真正做事的过程。

员工不会想着：“今天我要使用一下发票管理模块。”

他真正想的是：“我出差回来了，要赶紧把这笔钱报掉。”

所以，站在用户视角，完整的过程应该是：

准备报销材料 → 填写报销单 → 提交审批 → 领导审批 → 财务复核 → 等待付款 → 查询结果

这条路径，就是用户故事地图的“骨架”。

然后，我们再把每个步骤里可能涉及的具体行为补充进去。

比如，在“填写报销单”下面，可以继续拆：

• 选择报销类型
• 填写报销金额
• 上传发票
• 填写费用明细
• 选择收款账户
• 保存草稿

在“领导审批”下面，可以拆：

• 查看报销详情
• 同意申请
• 驳回申请
• 填写审批意见
• 转交其他审批人

这样一来，原本散落在需求池里的功能，就被重新放回了用户完成任务的过程里。

用户故事地图，横着看的是用户做事的顺序，竖着看的是每一步下面的功能细节和优先级。

它之所以叫“故事地图”，不是说产品经理要开始讲故事了。

而是它开始回答一件事：用户是谁？他想做什么？他为什么要做？为了完成这件事，他需要经历什么？

二、它和普通需求清单有什么区别？

我觉得，用户故事地图最有价值的地方，不是换了一种记录需求的方式，而是它改变了我们看需求的视角。

普通需求清单关注的是“系统需要有哪些功能？”

用户故事地图问的是“用户要怎样才能把这件事做完？”

这两个问题其实差别挺大的。

比如，我们把“发票识别”“消息催办”“批量报销”“费用统计”都排进了第一期。

功能很多，研发也忙得热火朝天。

但如果第一期没有把“填写、提交、审批、复核、付款”这条基本流程走通，那用户依然完成不了一次报销。

然后就是，功能做了不少，系统还是不能用。

所以，脱离实际场景单纯讨论“这个功能重不重要”，没有任何意义。

因为脱离用户完整路径之后，很多功能都可以“显得”很重要。

领导关心统计，财务关心合规，员工关心操作方便，研发关心系统复用。每个人都有自己的道理，最后的需求池就会变成所有需求优先级都最高。

用户故事地图会引导团队回到同一个问题上：为了让用户先完成一次完整的报销，我们最少要做什么？

也就是我们常说的MVP。

三、用户故事地图怎么用？

用户故事地图本身并不难，真正难的是画图过程中需要做取舍。

毕竟，贴便签谁都会。

判断哪些是主路径、哪些可以暂时不做、第一版到底要做到什么程度，才是产品经理真正要干的活儿。

第一步：先明确用户和目标

不要一上来就列功能。

先确认两个问题：

我们现在讨论的是谁？

他最终想完成什么事情？

在报销系统里，至少会涉及员工、审批人和财务人员。

如果这次重点讨论员工报销，就可以先把目标定义成：让员工顺利提交一笔报销，并最终拿到报销款。

“建设报销系统”不是用户目标，“完成一笔报销”才是。

这个区别很重要。

前者很容易让人一开始就讨论模块、页面和系统架构，后者会让我们先去关心用户到底怎么做事。

第二步：展开用户的主路径

接下来，把用户为了完成目标必须经历的关键步骤，按照顺序从左到右排出来。

还是报销这个例子：

准备材料 → 填写报销单 → 提交审批 → 审批处理 → 财务复核 → 付款 → 查询结果

这一步先不要拆得太细。

主路径最好控制在一个人能够快速看懂的范围内。如果第一层就铺了几十个步骤，那这张图大概率已经开始失控了。

主路径应该像一本书的目录。

看到它，团队就能大概知道用户从哪里出发，经过什么，最后到哪里。

第三步：补充每个步骤下的用户故事

有了主路径之后，再往每个步骤下面补充具体行为。

比如“填写报销单”下面，可以放：

• 新建报销单
• 选择费用类型
• 填写金额
• 上传发票
• 填写明细
• 保存草稿

“审批处理”下面，可以放：

• 查看报销详情
• 同意报销
• 驳回报销
• 退回修改
• 填写审批意见
• 转交审批

这个阶段最好让业务、产品、设计、研发一起参与。

因为同一个流程，不同角色看到的问题往往不一样。

业务知道现实规则，产品关注流程是否完整，研发会发现技术限制，设计能看到操作上的断点。

如果只是产品经理一个人关在会议室里，哼哧哼哧画完一张特别完整的图，然后发到群里通知大家“请查收”，那它和一份普通需求文档其实没有太大区别。

用户故事地图的价值不只在那张图，更在团队一起把事情想明白的过程。

第四步：排优先级，分出版本

故事补充完以后，需要在每个步骤下面按照重要程度纵向排序。

越靠上，越重要；越靠下，就可以适当延后。

然后用一条横线，把第一版必须完成的内容连起来。

比如，报销系统的第一版可能只需要：

• 员工填写报销信息并上传发票
• 员工提交报销申请
• 领导同意或驳回
• 财务完成复核
• 员工查看当前状态
• 财务记录付款结果

至于发票自动识别、智能填单、催办提醒、批量报销、统计分析，可以放到后续版本。

这里有一个很容易踩的坑：有些团队会按照模块切版本。

第一期做报销单，第二期做审批，第三期做财务复核。

每一期好像都交付了一个完整模块，但用户直到第三期结束才能真正完成报销。

这就很尴尬。

用户故事地图切版本，不是横着砍掉半条用户路径，而是在完整路径上先划出一个最小闭环。

第一版可以不够智能、不够漂亮，甚至有些地方需要人工处理，但最起码用户能把事情从头到尾做完。

第五步：把地图转成迭代计划

地图画完以后，不是拍照存档就结束了。

可以把切出来的用户故事继续拆成具体需求，补充业务规则、异常情况、验收标准，再进入需求池和迭代计划。

项目推进过程中，如果用户反馈、业务规则或者优先级发生变化，也可以继续调整地图。

它不是一次性的交付物。

否则辛辛苦苦贴了半天便签，最后变成会议室墙上的装饰品，多少有点浪费胶水。

四、哪些场景适合用用户故事地图？

我觉得，用户故事地图尤其适合以下几种情况：

第一，产品刚开始规划，团队还说不清到底要做什么。

第二，业务流程比较长，涉及多个角色和多个系统。

第三，需求很多，各方都觉得自己的需求最重要。

第四，团队需要定义MVP，但一直无法达成一致。

第五，产品已经做了一段时间，功能越来越多，用户体验却越来越割裂。

当然，也不是所有需求都需要画一张故事地图。

如果只是修改一个字段、调整一个按钮、修复一个明确的问题，直接写清楚就行。

为了改一个按钮，拉着十几个人开会画半天用户故事地图，也挺形式主义的。

工具是拿来解决问题的，不是用来增加仪式感的。

五、画用户故事地图时，最容易踩哪些坑？

1. 画成了功能架构图

如果地图最上面写的是用户管理、订单管理、审批管理、消息管理，那它大概率还是一张功能架构图。

用户故事地图的主路径应该是用户的行为，而不是系统的模块。

多用动词，少用系统名词。

2. 产品经理一个人画

一个人当然可以先整理初稿，但不能一个人完成所有判断。

尤其是复杂的B端产品，很多真实流程藏在业务人员的经验里，也藏在研发随口问出的那句：“这种情况失败了怎么办？”

把相关角色拉进来一起讨论，往往比图画得多漂亮更重要。

3. 只画正常流程

实际工作里，真正麻烦的往往不是正常流程，而是异常情况。

• 发票上传失败怎么办？
• 审批人离职了怎么办？
• 报销被退回后从哪里重新提交？
• 财务复核发现额度超标怎么办？

正常流程决定系统能不能跑，异常流程决定系统好不好用。

4. 把第一版做得太满

画用户故事地图很容易让人产生一种错觉：

既然我们已经把这些需求都想到了，那是不是都应该做？

不是。

想清楚和马上做，是两回事。

地图越完整，越需要克制。否则它只是把原来散落在需求池里的需求，整整齐齐地重新堆了一遍。

写在最后

我喜欢用户故事地图，不是因为它看起来专业，也不是因为满墙便签很有产品经理的氛围感。

而是因为它能把我们从一个个孤立的功能里拉出来，重新看见用户到底在做什么。

产品经理每天都会接触很多需求。

业务的需求、领导的需求、客户的需求、系统的需求，大家都在告诉你“这里要加一个东西”。

但产品经理真正要做的，从来不是毫无主见地听之任之。

而是把它们放回用户的完整路径里，判断哪些真的有价值，哪些只是局部视角，哪些现在必须做，哪些可以再等等。

需求清单让我们看见要做多少事。

用户故事地图让我们看见，为什么要做这些事。

而后者，才是产品经理存在的意义。