梳理不清产品需求，是众多后台产品经理的主要痛点之一；此篇文章，笔者将介绍如何利用用户故事地图，帮助我们梳理清楚后台产品需求。
领导需求不清晰、业务调研没方向、各个角色需求错综缠绕……都是我们梳理产品需求感到困难的原因，但为了赶进度，很多时候产品经理只是匆匆照着竞品画原型，后来发现各种业务逻辑有问题，需求没考虑到，结果要么是不断延期，要么就是重头再来。
一、什么是用户故事地图
用户故事地图，是指针对某一用户角色，选定一个具体、真实的业务目标，按主流程及分支流程梳理此角色达到这个业务目标所经历的每个业务节点，并以路线地图的形式展现出来。
它包括的要素有：
具体的用户角色
业务目标
实现业务目标的流程
业务节点
具象化的形式
二、用户故事地图的价值
为什么要用用户故事地图做后台产品需求梳理呢？
1. 清晰划分不同角色用户需求
系列第二篇：《后台产品设计系列：产品设计方式（二）》中提到，后台产品相比于前端产品，在需求方面最大的区别是不同角色需求差异很大，经常出现某个功能就是为一种特定的角色做的，有的角色需求甚至相互矛盾。
这就使得我们在思考用户需求时很难同时思考多种角色的需求，或把他们的需求杂糅在一起考虑，所以我们需要借助用户故事地图把每种角色区分开，分别梳理不同角色的需求。
2. 始终围绕真实场景，避免出现产品经理自以为是的需求
产品经理设计产品功能最怕的就是自以为是的揣摩用户，妄加需求。
我们都知道，产品的三要素是用户、场景、需求，而需求是在明确的用户和场景前提下才产生的，脱离场景谈需求都是耍流氓。
产品经理很多自以为是的需求就是因为想着想着就忘了场景，天马行空的想象，变得不接地气，沉浸在自己YY的世界里还以为这就是用户想要的。而用户故事地图就是帮助我们始终在这个场景下思考，不会偏离航道。
3. 以产品经理习惯的流程化思维梳理需求，减少混乱和遗漏
流程化思维是我们非常习惯的一种思维方式；因为这种方式逻辑性更强，有一条主线牵引我们的思绪，不会混乱，也减少遗漏。
4. 清晰的需求墙，帮助进行迭代规划
故事地图能够直观展示出该场景下的功能全景图，帮助产品经理更加清晰地规划而不至于迷失在零散的故事中。
三、如何构建用户故事地图
下面，我们以财务报销系统为例，详细介绍如何利用用户故事地图梳理需求：
1. 构建用户画像
用户画像是一种抽象又真实的用户模型；它是经过对一类用户特征的归纳，设置一个真实有代表性的人物作为这类用户角色的代表。
构建后台角色用户画像时，我们主要通过访谈的方式，了解这类角色的一些基本信息、形象、痛点或烦恼、目标或期望，例如对公司多个需要做财务报销的人员进行访谈后，构建了以下用户画像：
2. 寻找场景及目标
在这里，我们以最常见的场景举例：张总出差时，会请客户吃饭，出差回来后需要报销。这个场景中的目标就是报销成功，报销款回到自己口袋里。
3. 梳理业务流程
通过对现有报销流程梳理，我们将每个报销步骤放在报销路径中，就能看到一条清晰的实现场景目标的流程。关于流程的讲解，在《后台产品设计：流程设计（三）》有比较详细的介绍。
4. 调研痛点
没有好的方法，我们在调研用户痛点时经常是无头苍蝇，东问一句西问一句。现在有了前面的基础，我们的痛点调研就能够有的放矢，将一个大的流程拆分为多个小节点，针对每个节点深挖痛点，而当我们清楚的写下每个痛点或问题时，便已解决了一半。
5. 思考产品解决方案
如果一个痛点有多种方案，在故事地图中可以都列举出来，每个方案写在独立的便签纸上，实际做功能时再来权衡哪种方案更好，因为有的方案看起来很美好，但可能因为其他原因做不了；
如果一个痛点没有解决方案，在地图中就要清晰地把它标记出来，作为遗留问题，等待其他条件充足时再来思考解决方案，保证不会因时间过长而忘记。
6. 找到外部依赖、风险
虽然产品解决方案有了，但并不代表这些方案都能落地。
我们经常会在开发阶段发现，很多方案都受制于其他外在条件，比如你要做发票照片上传，并能在线预览功能，这就需要文件服务器的支持，如果文件服务器无法支持预览，那这个方案无论看起来有多正常、多合理，都是无法实现的。
所以我们要提前针对解决方案做预估，找到外部依赖条件，确定这些条件是否满足，如果无法满足这个方案所需条件，那只能摒弃进而采用其他方案。
而寻找风险就是需要未雨绸缪，提前知晓，提前准备应对方案。其实很多时候我们的风险就来源于前面的外部依赖。
经过上述六个步骤，我们针对这个场景就构建了一个完整、清晰的用户故事地图。用同样的方法，梳理其他场景，我们就能够很清楚的知道每个角色是什么样的，有哪些痛点，要怎么解决，需要什么条件，可能有哪些风险，这个时候，才能做到胸有成竹。
四、用户体验地图设计原则
原则一：根据阶段确定梳理流程的复杂度、颗粒度。例如刚开始理产品思路时，就应该先梳理主流程和重要分支流程，甚至分支流程都可以不用管，颗粒度也不用很小，聚焦一条线，形成初步的认识；
原则二：以业务目标为导向，而不是以梳理流程为目的；
原则三：每一楼层保证相同特征便签，每个便签只写一个痛点/解决方案/依赖条件/风险。
