“用户体验五要素”相信大家都很熟悉，本文将结合「用户体验五要素」，聊聊作者对B端产品设计五要素的一些看法，希望对你有所启发。

结合「用户体验五要素」，我也来聊下我对B端产品设计五要素的一些看法。

一、角色目标

用户是谁，他/她的岗位职责是什么，在履行职责时遇到了什么问题，为什么会有这些问题，没系统赋能之前，他/她是怎么解决这些问题的。

系统是为人服务的，为谁服务，需要充分识别出涉及的相关方，搭建整个系统服务的用户群体画像。

梳理相关方时，需要逐一深入了解各相关方的岗位职责（目标）、痛点（背景+问题点+当前解决方案），最终形成完整的用户画像体系，方便管理各相关方预期的同时，也更高效地解决用户的痛点、痒点及各流程事项的卡点。

在进行用户调研时，需要根据对方的岗位职责及工作内容代入到对方的视角中，比如跟财务聊，财务的工作是确保款项正确入账，你就不用纠结合同是否可以签的业务领域问题了。

在了解用户的痛点时，需要进一步了解目前没有系统支撑时，他是怎么解决这些问题的，是忽略这些问题，还是用效率较低的方式支撑着解决这些问题。

一般来说，优先处理后者，因为前者目前处于被忽略的状态，而业务还能正常运转，要么是发生的概率极低，要么是即使发生了，对业务的运转也没啥影响，属于重要（或不重要）/不紧急的事情。

完善好用户画像之后，需要让用户自行确定优先级，以确保能管理好用户的预期。

调研完所有相关方，完善好整个用户画像体系之后，需要综合对比考虑，从公司战略、相关方话语权、ROI等角度对所有相关方的诉求进行优先级的排序及沟通确定。

资源总是有限的，需求总是做不完的，而B端产品涉及的相关方又太多，有人的地方就有江湖，常见的如下：

1. 相关方之间的诉求是冲突的，如销售管理型的CRM，销售总是希望“自由点”，而管理者总是希望了解销售的一举一动，以便做好人员的管理。
2. 相关方的诉求是一致的，但优先级可能会有冲突，如：技术部分不甘于沦为成本部门，就希望做的CRM系统可以通过一系列营销工具带来更多的营收，而业务部门却认为只需要管好销售及内部流程即可，营销的事情不需要操心。其实站在公司的角度，两者的诉求都是合理的诉求，而且也肯定会朝着这些目标前进，只是需要分阶段实现，而先实现哪个，则需要进行充分的沟通讨论及协调。

产品经理不便于卷入这种“江湖斗争”，不然做事就会比较被动，所以需要拉齐所有相关方，就需求优先级及阶段目标达成共识，这样就可以与各相关方做好工作上的协同，保证整个开发节奏的稳定性。

二、产品目标

产品的长远目标及阶段性目标各是什么？

其实在第一阶段识别角色目标进行用户画像体系构建之前，对产品目标应该已经有初步的了解了，但还不是定稿状态。

如：CRM（Customer Relationship Management，客户关系管理）分好几种类型：

营销型CRM：重在通过更多的营销活动来带更多的客户；

分析型CRM：重在通过数据分析洞察客户，提升客户的转化率；

销售管理型CRM：重在对销售的管理，提升人效，降低成本；

可能长远目标，CRM系统会把这些范围都覆盖，但有一定的时间周期，需要拆分成多阶段目标逐步实现。而各阶段目标，则是相关方们battle的结论。

Battle完之后，确保大家对产品的长远目标及各阶段性目标达成共识，就可以确定产品调性，明确产品的边界，更好地达成各相关方诉求及产品目标。

每个人提的诉求都是一个个碎片化，我们需要根据达成共识的阶段性目标，兼顾长远目标将这些碎片串起来，从点到线再到面，这样产品的蓝图就出来了。

蓝图的绘制是很有必要的，代表了对产品的想象力，平时做需求也会考虑到后续的拓展性，方案更加系统化，也可以跟大家同步产品的迭代方向及迭代节奏，管理好各方预期。

蓝图没有定稿一说，产品是迭代出来的，不是规划出来的，所以不用因为迭代方向跟蓝图的差异有点大而感到沮丧，及时根据各方因素更新蓝图即可。

三、ER建模

确定了产品边界之后，就可以进行ER建模。

什么是ER建模呢？

其实我们B端产品，更多地是需要遵循物理世界的运行规律，将物理世界抽象为计算机可以识别的模型，来支撑物理世界中所发生业务的运转，抽象的这个过程就叫ER建模，ER建模的产物就是ER图。

ER图的组成部分有实体、实体属性、实体间的关系：

• 实体：我们要管理的对象，如：客户、联系人、跟进记录等等，抽象实体时有个小技巧：数据有唯一的ID，后续可能会通过ID查找该数据的，就可以定义为实体。
• 实体属性：该实体所具备的一些重要特性，丰富一下实体的画像，对实体有更清晰的定义。如客户，有客户名称、纳税人识别号等等属性，这样就可以明确该客户是一个公司，而不是C端个体。
  不同实体可能会有相同的属性，如：线索跟客户都有联系人姓名，都是记录该实体的联系方式，不必太过于避讳，只要确保实体的画像足够丰满、清晰即可。
• 实体关系：为了表示实体之间的关联关系，如跟进记录，是要跟客户关联还是跟联系人关联，完全是两种不同的业务模式。怎样的关联，1对1，还是1对N，即1个客户关联1条跟进记录还是N条，也是两种不同的业务模式。

示例如下：

1个客户下面可以创建N个联系人，一个联系人可以有多条跟进记录，即客户的跟进记录挂在联系人下面，而不是客户下面。建完模之后，整个业务场景就比较清晰了。

准确的ER图，可以提升自己对业务的认识，提高与用户及研发的沟通效率，也可以指导研发的数据建模：研发的数据库就是一张张excel表，通过“ID”将多个表关联起来做各种逻辑计算，从而满足系统中的各种数据运算，满足用户的需求。

四、事项流程及节点目标

B端产品很大一部分内容就是对各个实体进行各种逻辑判断、算术运算及增删改查等操作，对1个或N个实体进行流程审批、知会，从而支持发生在物理世界的业务运转。

几乎所有的B端产品都有一个特点：审批事项多、审批流程冗长。

审批流程本意是为了规范管理，但基本都会被层层加码：

1. 审批者的安全感：不履行自己审批的职责，迫于公司规定的管理职责，又不能把审批节点去掉，故在自己审批节点前面加上自己的下属，让下属做事项的审批工作，有了下属的认真审批，自己就可以“盲审”。
2. 因为某些低概率事件的发生而开设的审批流，比如外勤打卡审批，就因为出现部分人躺在家里打卡，而设立的外勤打卡审批流程，让其上级进行管理监督。其实大可不必为了部分人的作恶而一棒子打死所有人，可以让系统判断，一段时间内在同个地点打卡多次就给相关人员预警提醒，人为判别是否为正常的商务活动即可。
3. 领导变动或者管理重点变动：随着业务的发展，领导的人事调动或者管理重点也会随着变动，以支撑业务的运转。两者的共同点基本都是只会增加流程，不会删减原有的流程。因为在他们看来，目前的流程制度支撑了业务的正常运转，删减现有流程还得去排查是否会带来其他影响，删减了之后不出事还好，出事了就是自己的问题了，反正又不需要自己干活，权衡之下，就会在现在的流程上，叠加自己想要的流程，导致流程越来越多。

基于以上背景，我们需要对每个流程及流程上的每个节点都了解清楚，能用系统判断的，则无需人为核验，“如非必要，勿上流程，勿增节点”。

顺便提一下B端产品的价值，C端产品可以有用户量、活跃度等明确地指标体现产品及各迭代的价值，但B端产品是支撑业务发展及运转的，价值往往难以估量，导致B端产品经理的价值无法得到认可，比较枯燥。

冗长的内部流程往往是企业内部常见且头疼的现象，如果我们可以统计各流程所花时间及驳回率，通过技术手段及逻辑方案降低流程时长及驳回率，就可以大大提升企业内部的流程效率，这就是B端产品最好的价值体现。

五、故事地图及方案设计

经过了前面四个步骤的摸索之后，我们对用户体系及业务基本盘也基本摸清了，原则上可以开始设计方案了。

但因为之前梳理的都是枝干，很多细节会有所遗漏。而细节，往往是最影响用户体验及使用效率的，所以在设计方案之前，需要梳理一下故事地图，进一步挖掘用户痛点、痒点及卡点。梳理故事地图时，踩过几个坑：

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

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

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

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

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

如果用户有多个故事，可以用多个故事地图表示，如：销售的售前->售中->售后是一个完整的故事闭环，写周报是一个完整故事闭环。这样就可以用两个故事地图来记录，甚至售中可能涉及多个流程，也可以将一些复杂的流程单独作为一个故事地图。

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

梳理完故事地图，对用户的细节更加清楚之后，就可以来设计原型方案了。

设计原型时，可以按照“用户体验五要素”的思路逐步完成：

1. 战略层：讲清楚需求的背景及目标，让研发团队更加了解业务，提升沟通效率。
2. 在讲目标时，如果是一个稍微复杂的方案，最好是用流程图表达整个方案的逻辑判断点，“千言万语不如一张图”，先让研发小伙伴脑海里有个大致印象：要做什么、怎么做。

范围及结构层：用思维导图梳理需求涉及的改动点，思维导图的层级就可以表现出结构层。

框架层：设计原型方案及PRD文档。

B端产品的特点是页面也比较多，实体与实体之间的逻辑检验比较复杂，与其他系统交互也比较多，且复杂度是个增量的事情，经常需要回顾历史逻辑，维护起来工程量不小。

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

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

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

后面找到了比较高效管理原型的方法，将多个版本的原型集中在一个.rp文件里面：

一级目录：版本号，二级目录：需求，三级才是每个需求的战略层、范围及结构层、框架层，这样如果要找到对应页面的原型，直接查询即可：

每个需求作为一个目录维护，颗粒度也比较清晰。开发时，为了避免非当前版本的内容干扰到研发，可以通过项目配置，只托管当前版本的原型到托管平台中。

以上，就是高效管理Axure原型文件的方式。

产品经理的核心能力不是原型画的好不好，但原型质量就跟人的外貌一样，是一个产品经理的门面，太潦草也不好~

总结

综上所述，我把B端产品设计的思路划分成了5层：角色目标、产品目标、ER建模、事项流程及节点目标 、故事地图及方案设计。

每一层的搭建都会影响后续上层的质量，而在搭建上层时，可能也会发现底层的遗漏，可以进行查漏补缺，从而确保整个B端产品的方向正确。