随着互联网+各行各业的深入发展，互联网产品经理也在持续的向其他行业溢出。这也对产品经理的能力提出挑战：经常会遇到陌生的业务领域（2B产品更甚）。

对于这种新业务领域，产品经理在不了解商业模式、业务流程、不了解功能范围，怎么切入？这时可以试试花个30分钟，列举一个全局的用户故事脑图，它能帮助你快速建立对业务的商业模式、范围、流程、人员角色、各自需求的思考。

---

开始之前

我们知道，通常可以使用四个问题，来控制产品的思考范围：

• 谁是核心用户
• 他什么问题备受困扰
• 我的产品能如何解决
• 为什么是我们来解决，而不是别的产品

这几个问题问完，我们的产品就有一个大致的范围概念了，那么接下来怎么分析、分解呢？总有一种千头万绪无处下手的感觉。这时就可以考虑用户故事了。

为什么需要用户故事（或者至少用户任务）

用户故事的开发方法是跟随敏捷开发产生的一种需求分析、产品分解落地的方法。传统的敏捷开发会通过用户故事看板工具，来解决了团队一致性的沟通问题、产品的分版本、分阶段落地等问题。

而现在，为了能帮助自己梳理思考问题的逻辑链条，辅助后续工作的思考，可考虑将用户故事看板简化为用户故事脑图。作为用户故事看板的轻量形式，用户故事脑图在使用的过程中，可以让我们所有的功能都有场景、有依据，从而减少在产品设计阶段伪需求的产生。

再多轮业务的使用中，我认为它是一种独立建立角色设定、明晰场景、分析需求的一个很有效的方法。能够为后续的产品业务架构设计、产品迭代规划等提供高效的指导。

抽30分钟的时间，我们来看看怎么做一个有效的脑图用户故事

---

如何做脑图用户故事

常规单条用户故事的结构一般是：

我是XX【某个角色】，当我在XXX【某个场景】的时候，我希望能够XXX【做某件事情】，因为这样我就能XXX【实现某个目的】

当所有的用户故事罗列完成后，根据不同的角色、场景、任务之间的重要等级、关联和依赖程度去做功能开发的取舍、阶段版本的定义，从而推进到后续的产品设计、研发以及线上验证反馈阶段。

而脑图的用户故事中，因为是给自己做思路梳理的，所有它可以根据实际情况做简化。通常我会至少保留用户故事的基本结构，其他的信息在根据需要，做针对性深化。

另外，在做用户故事梳理还有一个原则，即：梳理阶段，只考虑用户与场景的需求，不考虑技术实现路径。

脑图用户故事的层级结构

我所使用的脑图用户故事的结构层级如下：

• • 第一层 典型角色
  • 第二层 典型场景（或者叫用户行为、骨干故事）
  • 第三层 典型的用户任务

有些人会在用户任务下再细分一些更细致的用户故事，不过我感觉自己用到第三层次已经可以了，就没有再细分。

第一层 典型角色

举个例子，假设我们要做一个餐饮点单的产品，应该怎么来列这个脑图用户故事呢？

首先来看典型用户。所谓典型用户就是和这个产品有关联关系的角色，通常会有直接角色和间接角色。

在餐饮点单系统里，点单肯定会有的角色就是 顾客和点单员（也可能只要顾客就行了）。

点单前和点单后会涉及到的角色，比如 点单后的主厨角色、配菜角色、上菜角色；以及点单之前的迎宾角色等。

这样其实我们能看到，直接的角色就是顾客和点单人，其他人可以被视为间接角色，这样就可以在列角色的时候顺便把他们的重要等级也思考一下了。（当然脑图里可以不体现）。

命名可以使用“我是XX”做假设引入。注意，这个假设在思考过程中很重要。

比如：

这一步的原则是有多少和系统产品有可能有关系的角色都罗列，也许某个角色后续分享下来没有使用场景，那么后续即使空着也无妨。因为这样可以让你的思考更全面。毕竟：做不做先不管，产品得先想到是不是~

第二层 典型场景

这里叫用户行为&场景&骨干故事，都行，随便你怎么叫。它的核心就是描述某个角色在和产品交互时的所有场景的划分。

这里要注意划分的分类必须时单一维度上完全分类，需要确保在这个维度上的所有场景都要有。比如常规的划分方法可以按生命周期、过程时间线等。

回到顾客点单场景，典型用户是顾客，那么如何做全顾客的场景？这时我们就可以考虑吃饭决策的全生命周期了。具体就是：

不饿->饿了->进店->点单->等餐->就餐->结账->离店

做为示例，这里简化了很多决策环节。（比如进店前还有叫外卖等决策的可能）

那么它的典型生命周期全场景就是：

当我不饿的时候

当我开始饿的时候

当我进店的时候

当我点菜的时候

当我等菜的时候

当我就餐的时候

当我结账的时候

当我离店之后

注意这里的格式时：当我XXXX的时候

当然根据业务情况也可以简化，比如这里我们的产品重心并不是所有场景完全发力，所以就可以根据情况做一下非重点场景的合并调整，如下：

第三层 典型用户任务

这里就到了这个脑图最核心的部分了，用户故事（也可以叫用户任务，随便怎么称呼了）。它的格式就是我希望能够XXX【做某件事情】，因为这样我就能XXX【实现某个目的】。

这里希望能够【做某件事】一定是从角色的口吻描述。

比如 点餐的时候，描述成 “我希望能过通过点图片选菜，这样我能知道菜怎么样”。这其实就是从我方技术实现的角度来描述功能需求了，后续可能对我们的产品设计思路产生“固化”的效果。

如果换成角色的口吻，这个描述建议写成“我希望能够看到这个菜是什么样子，这样我好直观的知道菜怎么样”。在这样的描述语境下，点图片选菜就成为了这个任务的一个可能的解决方案。同时，看视频选菜，看实物选菜、看模型选菜也都是这个需求所涵盖的解决方案。

这样梳理会帮助你释放大脑的禁锢，更好的去输出想法。

总之，能让各方理解场景的描述就是好的描述。如下：

这样从头到尾读下来就是：

餐饮系统，我是顾客，当我进店点餐的时候，我希望能够看到这个菜是什么意思，这样我好直观的知道菜怎么样。

这就是一个简单的用户故事描述了。

把所有的角色、场景、任务，都这样罗列之后，我们就获得一个餐饮产品的用户脑图了。以它为蓝本，再加上持续的角色调研、场景调研、头脑风暴，你的产品覆盖会十分完善。对后续的工作也能提供强有力的支撑。

（当然这个例子我就不在做更细致的罗列了）

---

最后的一些细节

这应该是谁的用户故事

有时候我们会遇到一些故事场景可能放哪个角色下都可以，这时候应该放到那个角色下面呢？个人建议无需太教条，不过可以遵循一个简单的原则：去想象一下如果不做这个需求，那个角色的反对声最大。这说明这个用户故事与他关联最大

那要做到什么深度呢？

这个深度其实可以继续细化到第四层（将用户故事按照功能实现的版本层次继续拆分），可还需要继续做吗？

我建议是跟着你的阶段走，大网大鱼 小网小鱼。找到适合自己的颗粒深度就行了。毕竟它是用来指定你做产品设计的。

接下来做什么呢？

后续可以针对用户故事，继续做功能分类，从场景关联性、角色任务重要等级等等，对应你的产品思路，产品功能的重要等级等，列产品业务框架，开始准备最小版本，进入持续一轮一轮的产品迭代落地了。

总之，找到你最适合的方法，让你的团队能够更好的转起来，就是好的方法。