从“用户体验五要素”推导为“B端产品设计五要素”

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

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

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

产品目标

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

ER建模

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

事项流程及节点目标

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

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

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