4 个步骤教你建立后台角色权限系统

角色权限系统设计可以更好的优化工作的流程步骤，本文分享角色权限系统设计的几个主要步骤。

公司的商户后台刚建立不久，之前仅能支持系统管理员和商户管理员两种角色使用，随着产品和业务线逐渐成熟，参与到整个产品中的人员越来越多了，涉及的部门和角色也由从前的一两种变成了多种，故由我主导了角色权限系统的重构升级。在此将工作心得记录下来，分享给需要用到的人。

先简单介绍下我司的 后台产品功能 ，我司主要业务是向B端企业客户销售一些智能硬件，客户买到产品之后会将产品关联到自己的商户后台，硬件会上传一些核心数据到后台供商户管理查看，所以我们的后台核心功能是：设备管理、商户管理、用户管理、数据管理、产品销售管理。

角色权限系统

了解完我司后台的大概功能后，我们来聊下角色权限系统。

角色权限系统属于策略设计范畴，它的设计非常考验一个PM对业务的理解力以及对自己后台所有功能的熟悉程度。做角色权限系统之前一定要先深度了解业务流程以及后台的所有功能模块，在不了解的情况下，多向相关同事请教，避免角色权限系统设计过程中出差错和逻辑漏洞。由于角色权限系统属于功能底层系统，很多的业务功能、前端功能都深度依赖角色权限系统，所以尽量在第一次出产品方案时就尽可能的考虑全面，减少后续不必要的返工，如果前期产品方案不够缜密，后期改动成本会非常大。

目前市场主流的角色权限模型是RBAC权限模型，具体技术原理可以阅读下这个博客http://www.cnblogs.com/lhyqzx/p/5962826.html，有人好奇为什么做角色权限系统设计还要了解技术架构呢？这个是为了让设计者能够设计出高效、安全、灵活且技术可实现的角色权限系统。

RBAC权限模型核心就是功能权限控制和角色产生关联，角色再和用户账号关联，即创建用户账号时选定一种角色，该角色里已经分配好了功能和权限。拿我们系统为例，由于有系统管理员和商户管理员的区别，即系统管理员可以查看所有的商户和设备数据，商户管理员逻辑上只允许查看自己商户下 的设备数据。所以我为了更灵活高效的去创建用户角色（比如：商务经理、商务专员、客服经理、客服专员等），我在用户角色之前又设置了角色类型，详见下图：

关于用户角色的创建权限上这里需要说明的是：如果贵司组织结构比较庞大，使用后台的角色人员涉及到各个职能部门，且不同职能部门又有不同的角色，那么创建、管理角色的权限应该下放到各个部门的leader，便于管理系统用户的效率。由于我司业务的特殊性，可以预估到会参与使用后台的角色大概十来种，所以我为了更加集中、高效、安全的管理用户角色，设定的只有超级管理员可以创建和修改角色。

角色权限系统设计流程

角色权限系统设计的大概流程如下：

一、工具准备

思维导图工具（mindmanager、Xmind都可，我用的Xmind）、word 、Axure.

二、给每个角色类型梳理功能架构图

功能架构图梳理是为了让设计者清晰理解后台所有的产品功能模块，以及各个产品功能之间层级关系，给每个角色类型都梳理一份功能架构图，可以让产品自身和开发以及项目成员都了解每个角色类型的区别。

• 比如：超级管理员这个角色类型，它应该可以管理后台的所有产品功能，并且拥有一些自己独有的功能权限；
• 比如：角色管理和账号管理功能我设定的只让超级管理员有权访问，其他角色类型全部访问不了，所以也不需要配置；
• 再比如：高级全局管理员应该有管理低级别角色类型的权限，而低级别角色类型不能管理高级别角色类型。

梳理功能架构图时可以根据一、二、三级这样的功能层次来画思维导图，有的后台系统可能非常庞大，那么是否需要把一级功能到一直到末级的所有功能包括界面按钮都全部罗列出来呢？这个需要看业务需求，看公司组织架构，多方面综合考虑再决定权限控制到哪一层，罗列到哪一级别的产品功能。通常情况下，权限控制到二/三层级基本能满足一个中小型公司的权限管理需求，再大型一点的公司，可以控制到更深层级的功能权限。

此外，我并不建议将权限控制到非常精细的级别，精细到可以控制前端页面上的每一个按钮，甚至每一个按钮的颜色以及交互效果，因为后台产品的核心是管理平台。管理无非增删改查四个操作，对于后台而言，管理的效率非常重要，如果权限控制的过于精细，在进行创建、修改角色时，效率会非常低。并且，如果不是系统的设计者理解起来会非常困难，对于页面上的一些关键按钮和操作可以加以控制。

注意事项：

• 层级划分清晰，不同级别的功能尽量用不同的字体区分开。
• 同类型的功能权限用不同的色块儿填充，一般来讲每种角色类型都至少会有两种类型的功能权限，（1）默认该角色类型拥有的功能权限,无须配置 （2）需要配置的功能权限。

之所以给不同角色类型的默认设定了一些功能权限，是为了创建角色和维护角色更加方便。比如：高级全局管理员角色类型对应的用户角色可能是各部门leader，像研发总监、客服经理、商务总监这样的用户角色，这些用户角色普遍会拥有较大的权限，同时又有所区分。假设系统有100个功能，那么我默认将这些角色可能会共同拥有的70个权限全部默认设定给高级全局管理员，将其余的功能设定为可自由配置的功能，那么当超级管理员去创建一个客服经理角色时，就只要配置剩余的30个权限即可。

三、设计功能原型

角色权限的内在规则逻辑设计好了，先和组内讨论，通过产品评审后可以考虑出产品功能原型了。

角色权限系统的开发一定是角色和功能是独立的两个模块 ，他们二者通过配置关系产生关联继而会出现不同的用户角色登录系统后会看到不同的功能界面，所以在画原型时只需要画出最全的功能即可。当系统内功能和角色数量相对而言都比较少的时候，角色权限管理功能可以考虑用横竖列表形式展现。当系统内的角色和功能数量比较多的时候，可以考虑模仿windows文件夹展开的交互用多面板形式来展现角色和功能的关系。

四、细化产品方案，形成PRD

将原型和脑图都梳理完毕后，最后就是把流程、细节从头捋一遍，将要点全部整理到PRD里，最后拿着PRD去和技术同学开技术评审会了。

完成以上四个步骤，基本就完成了一套后台角色权限系统的设计，如果觉得有用，请转发分享。

作者：Michael，Sensoro高级产品经理，产品设计经验丰富，主导过移动产品、IM产品、web前后台产品的多次重大升级。

关键字：产品经理, 权限

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！