编辑导读：原型设计是每一个产品经理的必修课，作为B端产品经理，如何做好一个逻辑清晰的B端原型呢？本文作者从三个方面进行分析，与你分享。

上一篇文章《如何快速接手一个甲方项目》讲到新项目如何快速接手，且快速梳理，这篇想说下在项目原型，脑图，逻辑都齐全后怎么绘制B端原型，毕竟设计到落地还是需要很大的一个工程，借这篇文章也对自己最近的原型设计踩的坑进行一个总结。

一、思路明了，功能流程清晰

比如“评价管理”这个词，大家直接能想到这个页面需要对所有的评价进行统一管理，评价有很多状态，每一个状态都需要在后台进行后续的操作，也就是需要在评价管理页面进行各种状态判定，且不说程序上逻辑上处理的复杂情况，从用户角度出发这样友好吗？用户需要遍历自己需要的评价状态，且不能统一管理某种状态评价。

对于“评价管理”我们应该优先想到的是好评，差评，这是我们随便就可以想到的，但对于系统来说必须想到所有的状态，因为但凡有一个状态想不到后面的流程就走不通或者会重构。除了好评，差评还有追评，追评的前提是差评才可以追评，好评肯定没有追评，那么这时问题就来了，何为好评？只有五星才是好评吗？四星呢？三星呢？二星呢？所以涉及到了一个中评的概念，这四个才是“评价管理”的完整状态。

评价情况列出后再去考虑系统业务，系统要实现什么？在原型设计上如何体现？再拿评价系统举例，我们先设想一个问题，为什么大家见很多的评价系统都有“追评”这个功能？存在及合理，追评最简单的场景是，用户差评了，我们需要让用户再次追加评价，将评价变为好评，这在网购平台经常可以看到，评价会影响商品和店铺的权重，还有一种场景就是“误评”，用户买完商品了或者是用户办完业务了，文字说的是好评，但手滑打了差评，这是追评的两种场景。然后我们在结合着两种场景去考虑追评业务，比如第一种情况的话，我们怎么能让用户追评为好评，这个操作和记录应该怎么在后台体现，如果是第二种场景，又应该怎么在后台体现，会涉及到那些功能模块和哪些字段。

二、脑图完整，页面结构清晰

功能流程和角色梳理清楚后，距离设计原型还差一步就是页面结构，对于已经清晰的部分我们先把系统中单个业务的所有状态拿出来，大家要知道后台业务是复杂且繁琐的。

对于评价管理前端来说，不用给用户看我们是怎么让一个刁蛮的用户从差评追评为好评的，只需要让用户看到，“哦，这是好评”，甚至有的平台连初始评价都不会保存，只留最后的结果。对于后台来说，记住一句话“所有的操作在后台都需要留有记录”，处理的就叫已处理，没处理的就叫没处理，好评就是好评，差评就是差评，都需要进行分类归类，所以我们需要持着这个思路来绘制脑图，切记，不要把两种状态放在一个列表又或者是一个列表需要两种角色来操作，这是大忌，我们可以给一个人多种权限，让他去和其他权限的人一起操作，但每一种权限都需要有自己的“空间”。

所以我们根据上面的思路，我们就会发现复杂的角色和功能都可以拆成相应的页面，而且根据这样的思路绘制出的业务逻辑以及流程都是非常清晰的，A列表数据提交后，会流转到B列表，这样是不会冲突的，那么如果我们不用这个思路去分类，就很有可能出现A列表和B列表的数据都会到C列表，而C列表内的数据可能有的需要二次操作，有的不需要二次操作，这样的页面对于技术来说就需要做判定了，而且根据情况不同，可能会更复杂，而且流程上不清晰。

三、确定细节，绘制原型！

最重要的细节！是公司的原型规范！公司的原型规范！公司的原型规范！重要的事情说三遍，新人一定要注意，不要让你画就直接开画，最后画了一天发现公司有规范~，上面的步骤做完后，先问一下领导公司有没有已有的规范参考，如果没有的话，在自行设计。

还有就是后台设计比较重要的了，字段要考虑清楚，拿随便一个业务来举例，谁来办的要有吧，这是用户，谁给他办的要有吧，这是办理人，时间，窗口，业务要有吧，地点要有把，信息来源要有吧，操作要有吧，这是一些比较重要的信息，便于后台人员操作的，还有的比如，办理人电话，用户电话这些信息就放在详情里就好了，不用都展示在外面，页面只展示最重要的信息，还有就是每个页面涉及到的状态和操作要梳理清楚，能做交互先做上，后期做PRD的时候就好做了。确定字段还有一个方法比较简单，就是直接问，问上游，问下游，问。。。都可以，但当然要有自己的思考拉，大概就这么多。

四、写在最后

最近这两篇文章都是针对B端新人的，因为我也是刚进入这个领域学习，就想把工作中的经验汇总写成文章供大家学习，也是对自己项目的一个总结，毕竟有刀才好削刃啊。

作者：胡子邯 ；公众号：产品经理的日常反思

本文由 @胡子邯 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议