一款产品的设计需要逻辑思维、故事思维和受众思维三种思维信息之间的高效传递。在产品的版本开始迭代以后，需求池中被取出的迭代需求总是以一种小块或者说模块的形式进入开发和迭代流程。而这一种碎片化的形式给整个团队带来的感觉就像在拼一幅没有参照的拼图，拼成啥样全靠脑补，不能给产品以及开发团队一个整体的视觉。而这造成的后果就是很可能出现排列优先级的错误，在多个版本迭代以后用户仍然看不到自己想要的东西。

如何解决这个问题？那么便是使用一个可以分析用户需求又可以进行统一整体化的模型工具——用户故事地图。

要想搭建用户故事地图首先必须具备故事思维。说到故事，我相信大家都不陌生，就是叙述一件事情的经过，是一种文学载体。那么产品中的用户故事是什么呢？同样，它叙述的是用户通过系统完成他一个有价值的目标的事。这一个过程也叫做“案例”。

举个例子：我口渴了打算去自动售货机买瓶水，我选择了一瓶农夫山泉，机器提示2元，我使用支付宝扫码完成支付，售货机给我吐出了一瓶农夫山泉。这一个过程就是“我”（用户）通过与自动售货机交互（系统）达成了买水这一目标。

而这一个用户故事则可以描述为：

名称：买水

事件：

1、在自动售货机选择水的品牌和查看对应的价格

2、机器跳转购买页面，显示购买数量和多种支付渠道

3、用户（默认）选择数量为1，选择支付宝支付

4、机器显示支付二维码和金额

5、用户核对金额

6、用户使用支付宝扫码、并输入密码

7、机器显示“支付中”

8、机器显示完成支付

9、机器吐出货物

10、用户取走货物，完成购水

可以注意到，整个故事的描述只有“用户做XX”和“机器做XX”，很多人在进行描述的时候可能会出现“用户支付完成后，支付宝返***调值到机器，机器显示完成支付”或者“购买1瓶水后，机器数据库中水的数量-1”，切忌出现这样的描述，“回调值”“数据库”“字段”等对于用户来说是不存在直接意义的，在用户故事里就只讲用户和与他接触的系统发生的事。而这样一个故事在被记录以后就可以用一张小卡片来表示，可以称之为“故事卡”。

现在我们有了一堆的“卡片”，但是这么一堆零散的卡片对于我们来说除了头疼以外没有实际性的作用。

所以，我们应该给每张卡片按照我们评估的完成时间进行一个大体上的“标号”，这个“标号”起到切入故事的作用也就是“故事点”，这样“有名称”“有事件”“有时间”的“三有产品”才是一张可用的“卡片”。

当然，完整的故事卡应该包含

1. Card（卡片）
2. Conversation（会话）
3. Confirmation（确认）

我认为所谓的“确认条件”也就是一个故事的结局，就像童话的最后王子是否和公主快乐的生活在了一起，就像他去打败巨龙的目的就是为了拯救公主获得美人芳心。而“确认条件”就是这一个用户故事最根本的需求，不必在乎故事的经过（会话），在故事开始之前就直接定位到结果。

举个实际的例子，我现在在我的网页上需要上传文件，于是就有了下面的这一个文件选择按钮（上传按钮我就不放了，放了容易出事）。

我需要上传“什么类型”“什么大小”的文件这就是一个实际需求，也就是“确认条件”。

比如我现在是一个网课平台，老师需要上传一份课件。那么我的“确认条件”就应该设置为

1. 文件类型：仅支持ppt、pdf、word、jpg、png格式文件。
2. 文件大小：大小50M以下的课件，上传时间不得超过5分钟，30M以下课件上传时间不超过3分钟，10M以下课件上传时间不得超过1分钟，否责判定网络超时自动重新上传，三次超时则终止。
3. 附加：强制改名，禁止上传同名课件；一旦检测到上传脚本文件则直接清理cookie，剔除登录权限；禁止截取文件后缀，以防止图片木马等伪装术；其余罗列各项。

– 第1个步骤中的便签表示 主要流程，橙色便签
– 第2个步骤中的便签表示 用户任务（user tasks），蓝色便签
– 第3-4个步骤中的便签表示 用户行为（user activies），橘色便签。Jeff 称这两行的内容为 “行走的骨骼”（walking skeleton）和 “主干”（backbone）
– 用户故事（user stories），黄色便签在每个用户任务下自上而下排列，便于我们确定优先级
– 一般来说用户会按照从左到右的顺序来使用你的系统（用户故事地图）

重要的设计流程可以分为这么四个步骤：

（1）第一步，进行产品定义

我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。

（2）第二步，梳理骨干故事

梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。

（3）第三步，拆分故事

在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。我们可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。

在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。

项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：

• 用户在这步具体做什么?
• 用户还有其他选择么?
• 用户怎么做才能更爽?
• 出现问题如何处理?
• 其他用户来到这里该如何处理?
• 在真实业务当中，发生特殊情况该怎么办？

所以这一步我们将尽量多的关注到所有场景的故事。做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。
（4）第四步，沟通确认

这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。完成所有故事梳理后，就出现了下面这张图：用户故事地图。

而如何创建一张用户地图呢？我也没有经验，所以我就只能引用过来这么一段方法：

创建用户故事地图的8个步骤

1. 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字，实际上是的。因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。

2. 使用静默头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是 用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：

   1. 根据你的产品规模，这个过程可能需要3-10分钟的时间；你可以观察大家的行为来判断是否需要停止。
   2. 基本上每张便签都会以一个动词开头，如：发送邮件，创建联系人，添加用户等。
   3. 这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton）部分。
   4. 这时可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些内容你可能没有想到，而其他人帮你想到了。

3. 然后，让大家将桌面上所有的便签进行分组，将类似的任务分为一组，其他的的类似

   1. 这个过程最好也让大家采用静默模式进行，因为这样做会更快。如果发现重复的内容，就略过
   2. 基本上分组会很容易完成
   3. 这时同样观察每个人的行为，判断大家是否已经做完，基本上这个过程需要2-5分钟

4. 选择另外一个颜色的便签，对每个组进行命名，并贴在每组便签的上部

5. 对这些分好组的便签进行排序，一般按照用户完成操作的顺序，从左到右摆放

   1. 如果大家无法决定顺序，那么顺序可能没有那么重要（明显）。
   2. 这一组便签，Jeff Patton称为 用户活动 （User Activities）
   3. 这时你的地图应该类似于
      

6. 现在，按照 “行走的骨骼” 用户行为 这行开始讲述用户故事，确保你没有遗漏任何用户行为和用户任务。这时一般由组织者进行讲述，其他人提出意见，甚至可以让最终用户来参与讨论。

7. 这时，我们已经完成了用户故事地图的基本框架；可以在每个用户任务下面添加更加细节的 用户故事（User Stories）了。这时仍然建议使用静默头脑风暴的模式来进行第一轮用户故事的产生，同时借助如Persona和Scenario等方式协助完成这个过程。一旦你完成了用户故事的创建，就可以开始划定你的 发布计划（Releases）了

   1. 一般我习惯在第一个发布中只选择每个用户任务的2-3个用户故事。这对于帮助大家排定优先级和范围将很有帮助。
   2. 基本上我们不必使用用户故事的标准句法（As a …）来书写这些故事，因为每张便签都处于我们的地图的特定位置，大家很容易识别其所处的场景和角色。

8. 最后，针对第一个发布的所有用户故事进行分解，确保我们的第一个发布越小越好，基本上你需要保证在1-2个迭代后就可以发布你产品的第一个版本。