万字长文！超全面的B端产品设计指南

以上整理需求的方式，是按照业务流程进行整理的。在这个分析过程中，因为我们的需求来自不同的部门不同的岗位，难免会发现有些需求是互相矛盾、互相冲突的。因此我们在整理后的列表中需要将这些矛盾的需求全部圈出来，然后快速地找到相关人员，通过进一步的沟通协调来消除矛盾的需求。

很多时候，需求冲突的真正原因是使用者与管理者之间的冲突。作为使用者，他的核心诉求是方便高效、省事，最好还能在某些方面获得一定的利益;作为管理者，他的诉求是流程规范、过程可追踪，杜绝损害公司利益的事情发生。

例如中介公司的业务员，经常需要带客户去楼盘看房，他们自然希望在考勤方面能够更弹性，有一些自由度。但是作为管理人员，他们也没有办法盯着业务员时刻在做什么，只能通过一些定位打卡等手段管理业务员，不让他偷懒。

从这个例子可以看出来，不同角色由于岗位不同，核心诉求也不一样。在发生冲突的时候，笔者的建议是以企业的生产经营为核心，首先确保经营活动的规范化、流程化进行，在这个基础上增加为普通使用者考虑的易用性设计与情感化设计，让他们感受到产品不单单是一个反感排斥的工作系统，而是真正帮助他们提高工作效率的产品。

完成这一步后，才算是将整个产品的系统需求全部整理出来。以后每次迭代就是在业务需求与用户需求的基础上，创建新的系统需求，不断完善、丰富产品。

终于，我们进入到系统建设环节，真正开始设计一款产品的形状了。在这之前，我们先探讨一个问题：B 端产品和 C 端产品在产品设计上有什么差异性?

笔者认为，绝大多数 C 端产品的设计逻辑会把用户体验与效率放在首位。追求极致的简单好用与高效。在整个产品设计上比较侧重用户的感受，精心打磨页面与交互，尽量少让用户做选择，保持产品的易用性与流畅性，都是做 C 端产品设计的不二法门。

但是做 B 端产品时，所有的产品设计都是为「流程」服务的。体验和效率未必是设计的重心。很简单的一个例子就能明白，企业买一款中介 CRM 产品，不是为了让业务员更轻松，做业务的时候更「省事」，而是为了将整个卖房的流程管理起来，做标准化的经营，为经营决策提供更准确科学的决策。B 端产品更多是通过计算机技术实现企业的信息化管理，对企业流程进行优化升级，从而达到降本增效的目的。

由此可以看出来，做 C 端产品更注重对「人」的理解，要求产品经理具备同理心，感知用户的能力。而做 B 端产品更注重对「业务」的理解，要求产品经理具有系统性的逻辑思维，富有理性地对企业业务进行全面梳理与诊断，给出合理有效的解决方案。

在规划产品原型的过程中，产品的信息架构设计是重要一环，其中菜单结构设计、CRUD 原则与 RBAC 模型的应用，可以帮助我们设计出更合理、高效的产品形态。

1. 菜单结构设计

常见的菜单结构设计有两种，以「人/物」为主线，或以「事」为主线。

大部分的通用型 B 端产品由于各行各业的垂直差异性，无法做到统一的流程管理，而产品需要满足尽可能多的行业，因此只能以「物」为主线划分菜单结构。例如将 CRM 系统划分为线索、客户、联系人、公海、商机、合同等等，都是以「人/物」作为划分的标准。

这种划分方式在一定程度上来说是有缺陷的，因为在实际的业务流程中，物与物之间的传递有可能交错，例如在房产交易、确权、归档的几个环节中都涉及到合同的流转，而这种菜单结构没有充分体现这种流转的特点，同时不同岗位的职责权限也有可能交错在一起。

而专注于垂直行业的 B 端产品则往往以业务流程的职责划分为菜单划分的标准，也就是以「事」为主线的设计方式。这种设计方式的好处是可以有效的避免重复和混乱的现象，对整个系统的架构都是非常清晰明了的。

CRUD原则

在互联网，各类互联网书籍都提到过 CRUD 原则，也就是将新增、删除、查询与修改等操作合并成一个管理页面。例如一个订单管理页，包含了新增订单、删除订单、查询以及修改订单信息等不同的操作。

但是在很多情况下，一个 ERP 系统中，录入订单是由业务员录入的，后续由销售人员更新订单的信息。当发现退款时，由财务或售后人员撤销订单。由此可见这些所谓的「管理」操作往往不是由同一个角色完成的，如果合并在同一个管理页面会产生很多职责权限混乱的问题。好在现在越来越多的产品也意识到这个问题，在菜单设计上尽量避免使用「某某管理」这样的字眼，而是根据业务场景，更灵活地划分菜单的范围。

上面这段话的意思，难道是说 CRUD 原则是错的?其实并非如此，只是 CRUD 原则对于系统创造的东西才适用，例如管理系统用户、管理数据字典、管理权限这类的东西就适用该原则。对系统用户的增删改查，通常都是由管理员操作的，这个时候我们把这些操作都放在同一个界面就是合理的场景。

RBAC权限模型

B 端产品的权限设计通常都是适用 RBAC 模型，也就是每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问与操作权限。建立一个「用户 – 角色 – 权限」之间的对应关系。

此时，用户与角色，角色与权限都是多对多关系，即一个用户可以对应多个角色，一个角色可以分配给多个用户，一个角色具有多个权限。当用户比较多时，可引入用户组，既对用户分组，将角色与用户组进行关联。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!