经过了前面四个过程的摸索之后，我们对用户体系及业务根本盘也根本摸清了，原则上能够开端规划计划

、故事地图及计划规划

经过了前面四个过程的摸索之后，我们对用户体系及业务根本盘也根本摸清了，原则上能够开端规划计划了。

但因为之前整理的都是枝干，许多细节会有所遗失。而细节，往往是最影响用户体会及使用功率的，所以在规划计划之前，需求整理一下故事地图，进一步挖掘用户痛点、痒点及卡点。整理故事地图时，踩过几个坑：

• 把它放在第一个环节，那时候对用户、对业务都不熟悉，导致沟通功率比较低下，用户也会质疑你的专业才能。
• 把故事地图跟业务流程图混在一同，导致整个故事地图比较混乱，达不到了解用户痛点、痒点、卡点的意图。
• 将多个用户的故事杂糅在一同，整个故事线比较割裂。

截取部分反例：多用户的故事杂糅在一同及太偏向于业务流程。

脱敏之后，截取部分正确的例子：一个用户角色、一个故事整理出一张故事地图。

用户故事地图主要是为了更直观地了解用户方针、为了达成方针做出的一系列动作，做动作时接触到的点及整个过程的心情动摇，以便与用户达成共识，更好地站在用户的角度解决问题。

故事地图重在整理整个事项闭环中用户的心情变化，所以应该从用户兼顾事项闭环的角度绘制故事地图。

如果用户有多个故事，能够用多个故事地图表示，如：出售的售前->售中->售后是一个完整的故事闭环，写周报是一个完整故事闭环。这样就能够用两个故事地图来记载，甚至售中或许触及多个流程，也能够将一些杂乱的流程独自作为一个故事地图。

总而言之，B端产品是一个多事项流程、多用户参加的“混乱性”体系，不需求强硬地杂糅到一张故事地图里边，能直观记载及表达用户心情即可。

整理完故事地图，对用户的细节愈加清楚之后，就能够来规划原型计划了。

规划原型时，能够依照“用户体会五要素”的思路逐渐完结：

1. 战略层：讲清楚需求的布景及方针，让研制团队愈加了解业务，提高沟通功率。
2. 在讲方针时，如果是一个略微杂乱的计划，最好是用流程图表达整个计划的逻辑判别点，“千言万语不如一张图”，先让研制小伙伴脑海里有个大致印象：要做什么、怎么做。

规模及结构层：用思维导图整理需求触及的改动点，思维导图的层级就能够表现出结构层。

结构层：规划原型计划及PRD文档。

B端产品的特点是页面也比较多，实体与实体之间的逻辑查验比较杂乱，与其他体系交互也比较多，且杂乱度是个增量的作业，常常需求回顾前史逻辑，保护起来工程量不小。

之前我是一个版别一个.rp文件，且该.rp文件中的原型及PRD只会保存本次版别要做的内容，把整个.rp文件托管到Axure Cloud或蓝湖等原型托管东西，再分享链接给研制即可，研制也就很清楚地知道本次版别的作业内容。

这样做有个弊端便是我要找到某个页面的原型，在原有基础上修正，就会非常难找，需求查找前史版别记载，判别最近哪个版别有改到这个页面的原型，比较费精力。

有时候找到的并不是最新的原型，如：1.10就有改到这个页面的原型，但我没留心，找到了1.5版别的原型，改动起来就比较麻烦，功率比较低。

后边找到了比较高效办理原型的方法，将多个版别的原型会集在一个.rp文件里边：