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

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

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

RBAC权限模型

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

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

比如某个销售部门的员工在系统中是一个用户组，当新的销售员加入时，只需要设置他所在的用户组，就会将这个部门关联的权限赋予这位销售员。设置用户组还有一个好处，当这个部门的权限发生变动时，只需要调整这个用户组对应的角色权限即可，不需要调整每个用户和角色对应的关系。

以上三点是我们在做系统建设时最关键的核心设计点，相信经过以上的思考之后，结合上一阶段整理的系统需求列表，在我们的脑海里已经有大致的产品解决方案了。接下来的我们可以开始画原型、画界面，将文字性的想法通过形象化的方式展现出来。因原型的设计不是本文重点，在此不再赘述。

到这里，相信你已经对 B 端产品设计的全流程有一个清晰的思路了。韧哥在《产品经理必懂的技术那点事儿》一书中曾写道：

产品经理必须习惯与孤独为伴，这种孤独不是没有朋友的孤单感，而是指思考和决策的过程并不会有人给你明晰的指引，只能靠自己的独立思考和理解给产品赋予生命力，做出关键决策。

本文当然也不是一个教你如何做一款成功的 B 端产品指南，而是希望在你做 B 端产品时，能够提供一些设计的思路帮助你少犯错，沿着正确的方向思考问题。产品路上并不孤独，愿你我共勉。

（编辑：西安站长网）

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