本文针对初阶的产品经理、产品体验设计师，以及承担部分产品边界工作的交互设计师，较为系统地介绍了中后台权限系统的模型组成以及元素梳理、流程界面设计的诸多要点，读者可以以此来自查梳理内容是否充分以及获取权限界面设计中的要点干货。

1.什么是「权限设计」

“权限设计”是中后台的底层设计，用于明确操作人员可在平台内能做什么；即什么样的人，可以做什么样的事。

1.1.权限的意义

让使用者在有效的限制范围内访问被授权的资源。

让管理者基于系统的安全规则与策略，控制不同用户合理访问对应资源。

正是有了权限系统，才可以让工作群组内不同人员、不同组织的分工，让不同角色专注于自己的工作范围，也可以降低操作风险发生概率，也便于管理。

1.2.权限的应用

权限设计的应用主要有两种场景，分别是版本切割、角色权限管理：

角色权限管理：角色权限管理顾名思义是根据用户角色类型进行权限分配；一个角色对应一组权限组，一个用户可能有多个角色。适用于中后台逻辑复杂功能模块繁多，需要对系统按权限进行切割的应用场景。

版本管理：部分中后台存在商业化诉求，基于前者的角色权限分配（也有可能不存在角色区分），再将完整的系统进行功能切割，将整个系统按功能切割为普通版、进阶版，甚至更多版本；这些版本功能范围基本处于一个包含关系。

在B端中后台的设计中，最常见的应用场景为“角色权限管理”，角色权限管理涉及的维度也会比“版本切割”更为复杂，本指南会着重介绍角色权限管理场景下的设计。

1.3.权限设计要求

好的权限设计，需要达到以下三方面要求：

系统安全：基于系统的安全规则和策略进行设计，同时需要降低用户操作错误导致的风险概率。

关系明确：需要界定权限的边界与关系，遵循一定的规则与用户进行关联。

拓展性高：需要确保权限管理的拓展性，系统的能力建设是持续的，用户也是不断流动的；保持高拓展性以此降低变更对安全性、稳定性的影响。

1.4.权限设计的工作范畴

界面设计：权限查询、管理与授权等一系列页面设计。

业务梳理：权限构成、赋予以及行使的逻辑、元素的梳理。

数据验证&管理：数据管理层面，最终目标是可被表达成一个运算则式，体验方案的合理性与拓展性，验证设计的有效性。

底层架构开发：偏向于开发层面的系统底层架构设计与研发。

权限系统的复杂度决定设计需要介入的层级深度；一般设计师在权限设计中的范畴包括厘清权限的业务逻辑、关注页面本身的设计，其他的数据层面和实现层面即可交由产品和开发。

2.怎么做「权限设计」—业务梳理

2.1.准备工作：权限模型的了解与选择

在业界有很多关于权限系统的技术模型，常见的有ACL、ABAC、DAC、RBAC等等，不同体量的权限系统，我们可以参考不同的权限模型进行梳理和设计。

2.1.1.RBAC0模型

RBAC0的基础理念是将“角色”这个概念赋予用户，在用户与权限之间通过角色进行关联，实现灵活配置。

RBAC模型的三要素为：用户、角色、权限。

用户：是发起操作的主体，例如：后台管理系统的用户、OA系统的内部员工、面向C端的用户。

角色：用于连接了用户和权限的桥梁，每个角色可以关联多个权限，同时一个用户也可以关联多个角色，那么这个用户就有了多个角色的多个权限。

权限：用户可以访问的资源，包括：页面权限、操作权限、数据权限。

* 2.1.2.ACL模型

ACL为查询操作对象的权限控制列表。当权限系统体量小，用户直接对应具体功能点即可满足系统诉求时，可以考虑使用ACL模型作为参考。

ACL权限中，只有用户、权限这两个要素：

* 2.1.3.RBAC1模型：基于 RBAC0 加入角色继承

RBAC1模型是在RBAC0模型基础上，引入了角色继承的概念，即角色具有上下级的关系，每个等级权限不同，从而实现更细粒度的权限管理。

* 2.1.4.RBAC2 模型：基于 RBAC0 引入角色约束控制

RBAC2模型是在RBAC0模型基础上，对角色进行约束控制。RBAC2模型中添加了责任分离关系，规定了权限被赋予角色时或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。主要包括以下约束:

互斥关系角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，互斥角色是指各自权限互相制约的两个角色。例如：设计部有交互设计师和视觉设计师两个角色，他们如果在系统中为互斥角色，那么用户不能同时拥有这两个角色，体现了职责分离原则。

基数约束: a.一个角色被分配的用户数量受限；b.一个用户可拥有的角色数目受限；c.同一个角色对应的访问权限数目受限；以此控制高级权限在系统中的分配。

先决条件角色: 简单理解即如果某用户想获得上级角色，必须得先获得其下一级的角色，以此为一个先决条件。

2.2.开始梳理：基于RBAC模型盘点要素

RBAC0在实际工作中用得较为频繁，且对应初阶的设计师对于权限的理解也较为有帮助，所以本文接下来会基于RBAC模型来介绍权限系统的梳理及设计。

2.2.1.第一步：盘点角色

角色是连接用户和权限的桥梁，在这一步对参与系统的角色进行穷举，需要保证系统的运作能否绝对闭环，所以明确系统中的角色至关重要。

如何进行角色盘点，主要有以下两种方式：

参考组织本身的岗位划分：绝大多数情况下，系统中的工作职责与实际工作岗位有较为紧密的相关性，我们可以参考已有的岗位来盘点系统中的角色。

?举例，研发运维工具中的角色定义，不同的岗位对应不同的角色拥有不同工具的使用权。

根据任务流盘点：根据系统任务流对角色进行穷举，即盘点需要创建哪些角色进行任务闭关。

?举例，支撑A平台的智能客服知识库，角色是我们在产品规划过程中为其定义产生的。

本步骤产出物：「角色列表」

2.2.2.第二步：盘点权限

权限是用户能够访问的资源，本步骤需要将系统中所有权限点按照类型进行整理归类，最终成表。权限点主要有以下几种类型需要盘点：

页面权限

通俗讲即用户在系统内可见的页面，由导航/菜单来控制，包括一级导航/菜单、二级导航/菜单，甚至三级导航/菜单；只要用户有对应导航/菜单的权限即可访问页面。

?举例，智能客服知识库系统的页面权限：

操作权限

通俗讲即页面的功能按钮，包括查看、新增、修改、删除、审核等等。

?举例，智能客服知识库系统-敏感词管理-黑名单页面的操作权限：新增黑名单、修改、删除

在实际操作场景中，部分操作权限会因状态而发生变化，在盘点操作权限时，需要使用状态流转化图来检查是否有缺漏。

数据权限

数据权限就是用户在同一页面看到的数据是不同的，比如：A部门只能看到其部门下的数据，B部门只看B部门的数据。数据权限分割的解决方案为：创建用户组——将相同属性或相同数据范围诉求的用户进行编组，不同的用户组则享有不同的数据权限。

根据用户组是否有上下级的关系，可将用户组分为：具上下级关系用户组、普通用户组。

具上下级关系用户组:最典型的例子就是部门组织。

?举例：

针对事项的受理审批有较为严谨的流程，各个单位需要各司其职，且公众办理的事项隶属于各级层级区域，所以平台权限系统需要形成较为严谨的区域结构和部门组织。例如，市公安局、民政局、水利局的办事数据是对立的，我们可通过部门组织建立的用户组来隔离数据权限。

普通用户组: 没有上下级关系的用户分组。在日常系统最常见的普通用户组为“项目组”，按项目组来划分用户的数据权限。

?举例，以应用项目的纬度控制用户可访问的数据范围。

本步骤产出物：「权限点列表」

2.2.3.第三步：连接角色权限

本步骤主要工作在于连接权限点与角色的关系，最终整理出一张完整的角色权限表。在梳理角色和权限的关系时，可以借助设计分析方法“角色任务行为穷举”来进行权限点转化和连接。

通常情况下，用户为达成目标而需完成某些任务，这些任务以及任务的聚合往往会影响我们对于整个系统信息架构的设计考量。所以各个角色的任务经常与我们的页面一一对应，从而产生页面权限。而又因为完成任务需要进行一些特定的行为，而这些行为又与操作按钮一一对应，从而产生了操作权限。

?举例：

本步骤产出物：「角色权限总表」

2.2.4.第四步：设计用户导入与授权流程

在建立了角色与权限的关系后，需要去明确用户授权/导入的方式，并给导入的用户赋予角色权限。

明确账号体系

有部分公司域下的中后台，用户已有有统一的验证方式，例如：腾讯OA身份验证；也有部分中后台需要用户创建独立的ID账号密码作为身份验证。我们首先需要去明确我们设计的中后台是以上哪种方式作为身份验证，这将影响用户导入流程的设计。

初始用户授权流程

已有账号：如为公司域下中后台的用户导入，用户账号为现成的我们不需要考虑用户的账号。可直接为用户赋予权限，授权分为两种方式：为用户选择角色、为角色添加用户。

为用户选择角色可用在单个授权的场景，以下为授权流程可供参考：

为角色添加用户可用在批量授权的场景，以下为授权流程可供参考：

为丰富场景，提升体验，建议两种方式共存。

无账号：如需要用户创建ID的用户导入，则适用于以下流程：

为保障安全，邀请码需具有时效性。

授权申请流程

在实际工作中，用户为完成某项任务却无权限时，需要为用户提供清晰的申请流程。申请权限有两种场景。

场景一：权限存在岗位身份之分，身份与某组权限进行绑定，用户主动申请岗位身份并获得审批通过后，即可获得该组权限，流程参考下图：

场景二：用户在访问系统时，系统页面提示用户无访问/操作权限，用户针对该页面/操作进行权限申请，通过后即可获得该页面/操作权限，流程参考下图：

绘制状态转换图

如果需要展示状态转换关系，关注状态变化过程，甚至是检测流程是否存在缺陷，我们可以通过绘制状态转换图来梳理流转状态。使用状态图的过程中，设计师可以清晰的了解同一界面的各种状态，便于对设计方案系统化的进行设计。在同一界面中，可以模块化对比设计差异内容。

导入/授权后的消息通知

消息通知可以及时地将状态、内容的更新触达到用户。在权限系统中，导入用户环节或者是审批用户权限环节，都离不开及时的消息通知。特别是导入用户环节，为了确保安全性，邀请码具有一定的时效性，所以消息的及时传递非常重要，务必需要对用户进行及时的消息推送。

3.怎么做「权限设计」—界面设计

3.1.页面权限设计点

无权限页面申请指引设计

在2.2.4章节中，我们提到用户在实际工作中为完成某项任务，对无权限页面/操作会存在申请的场景诉求，我们除了要为用户提供清晰的申请流程，也需要有清晰的指引，实际上也是针对空状态的设计。

线上申请：用户通过触发申请按钮，发起申请，并在线上填写表单完成申请。在此场景下，除了申请按钮，我们需要也很明确的告知用户当前为无权限的状态，甚至将原因也给予简单说明；同时建议告知用户申请的审批人是谁，需要审批多久。

?举例：无权限页面

线下申请：页面仅告诉用户申请方式，一般为授权人的联系方式。

?举例：无权限页面

3.2.数据权限设计点

数据权限范围的展示与切换

在2.2.2章节中，数据权限的不同导致用户在同一页面看到的数据是不同的，数据权限的范围可由具有层级关系的组织架构划分，也可由普通用户组进行划分。通常，系统允许用户拥有单个或多个数据权限；所以在我们的系统界面中，需要有承载数据权限范围展示和切换的设计。

由于数据权限的展示和切换控制着用户对于整个系统的数据范围，故需要存在于系统架构的第一层级，一般可独立放置于一级菜单之上。

? 举例：项目切换

3.3.操作权限设计点

无权限操作展示设计

可申请

对于开放申请的操作权限的展示，可将操作权限点置灰，表示用户当前不可操作；在用户hover置灰权限点时，提供气泡提示置灰原因为无操作权限并提供申请权限入口。

不可申请

有些系统要求用户可见操作全貌，即所有操作无论是否有权限都为可见的；若无权限则且不可申请，则直接置灰操作

有些系统要求"可见即可操作"，即为有权限的操作则显示，无权限的操作则隐藏，这里就需要前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限。

站在用户体验角度，更建议用后者这种方式进行权限隔离。

总结

在中后台中，权限系统或许不像业务模块一样备受重视，仅仅只是中后台背后默默支撑的功能，但却是必不可忽视的，正是有了权限系统，才可以让工作群组内不同人员、不同组织的分工，让不同角色专注于自己的工作范围，降低操作风险发生概率，便于管理。

在实际项目中，会遇到多个系统、多个用户类型、多个使用场景，这需要具体问题具体分析；但万变不离其宗，不管多么复杂，逻辑如何变化，最核心的RBAC模型还是一样适用。