设计师在设计时，往往会抽象出多个对产品有需求的角色，然后根据角色的特点来梳理使用场景并进行设计。
当角色之间的使用场景不冲突、不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。 例如：网易云音乐为需要同时听歌曲和电台的用户提供了全部功能。
当这些角色的使用场景完全不重叠、流程对立时，我们会设计两个完全独立的系统，比如滴滴的司机端和乘客端；
但除了上述两种情况外，在大多数B端产品中，基于流程公平、信息安全等因素，各个角色的使用场景部分通用，部分隔离。 这时候就需要引入“许可制度”。 。
设计师有时会对角色权限系统感到有点害怕。
一方面，因为角色权限系统的配置是一个非常后端的管理功能，所以在竞品研究过程中很难从上帝视角来剖析其中的逻辑，也很难在你的产品上搞清楚。自己的; 另一方面，对于角色权限系统来说，做得好并不代表设计能力有多好，但如果做得不好，就会导致整个流程受阻，产品崩溃。 因此，设计师常常回避许可系统。
下面是笔者在权限设计方面的几点经验，并提供一些所谓的经验套路。 我希望所有的设计师从现在开始都微笑着迎接许可要求。
2、基于技术模型-RBAC模型的设计
在设计之前，最好先了解一下技术模型。 业界接受度较高的功能权限模型是RBAC（基于角色的访问控制）模型。 其基本思想是给用户赋予“角色”的概念，在系统中通过角色将用户和权限关联起来。 通过这种方式方法实现了灵活的配置。 下面简单介绍一下与模型和设计相关的几个点。
1. 基本RBAC模型
如果没有角色的概念，系统每次添加用户时，都需要为该用户配置权限。 下图展示了wiki中直接的用户权限管理方式。 可见，管理成本是巨大的。
引入“角色”的概念后，下图是RBAC模型中最基本的模型：用户和角色可以是多对一或多对多的关系。 当用户的角色为多对多时，当前用户的权限是多个字符的并集。
此时，只需为角色授予权限即可角色权限设计音效，可以大大减轻管理负担，并将用户与权限解耦游戏开发素材，提供更大的灵活性。
2、引入用户组概念的RBAC模型
在大型平台的应用中，想象一下，如果有数万个用户，当增加一个新的角色时，可能需要为大量的用户分配新的角色。 工作量还是很大的。 这时候就可以引入用户组的概念了。 如果某些用户的使用场景比较一致且基础，我们可以将这些用户打包成一个组，并根据这个组的对象来分配角色和权限。
同样，如果权限很多，也会存在同样的问题。 解决方案是引入权限组的概念，将一组使用场景相对固定的功能或权限打包成组，并分配给角色。 但一般来说，系统中权限函数的数量相对有限且可控，因此在实际应用中很少使用权限组。
下图展示了如何在Mac系统中添加用户组并以用户组为单位配置权限。
需要注意的是，即使存在用户组或权限组，用户或权限仍然可以直接与角色关联。 这可以取决于具体的业务情况。
3.角色继承的RBAC模型
在业务场景中，如果需要区分角色：设计总监、设计组长、设计成员，并且管理方式向后兼容，则需要使用角色继承的RBAC模型。 上级角色继承下级角色的所有权限，并可以被授予额外的权限。
这时除了定义角色之外，还需要管理角色之间的关系，用关系来体现角色的层级关系，从而达到继承权限的效果。 角色继承关系主要有两种类型：树形图和有向无环图。
这种传承关系往往来自于公司团队的组织架构。 在这种情况下，角色往往会与组织结构相关联，以达到继承角色模型的效果。 如下图所示，赵先生的角色是“三级组长”。 团队中有多个与他平行的“三级组长”角色，但它们隶属于左侧的组织结构树。 每个级别负责人只有查看和操作自己下级子节点的权限。
4. 受限的RBAC模型
在一个产品或系统中，某些角色可能需要隔离，不允许同时分配给同一个人。 这与众所周知的一句话“你不能同时担任‘运动员’和‘裁判员’是一样的。”
因此，对于一组多个角色来说，只能存在单选关系，但多组角色可以共存。 如下图所示，一个用户可以同时是设计者和管理员，但在设计者角色组中只能分配一个角色，在管理员角色组中只能分配一个角色。
此外，限制可能是数量上的。 例如，一个产品组中必须有且只有一名管理员。 不允许删除或重新分配管理员角色。 仅允许变更负责人的角色。
限制模型不仅影响分配过程，有时即使有多个角色，因为不同角色可能会与相同功能或数据的使用发生冲突，因此使用也需要受到限制。 如下图所示，同一时间只允许一个身份登录。
根据不同的业务需求，限制形式有很多种。 需要注意的是，不能仅仅依赖后端限制，而应该在前端显示明确的规则和适当的限制，以避免用户错误和沮丧。
3、权限的拆分与设计
通过RBAC模型可以很好的建立用户、角色、权限之间的关系。 但具体的关系是怎样的，“权威”这个抽象概念又是如何具体规划的呢？
这些都需要分析清楚，才能进一步设计出完整的权限体系。
首先你要知道，一般产品的权限由页面、操作、数据组成。 页面和操作是相互关联的。 您必须拥有页面权限才能在页面下分配相应的操作权限。 可以对数据进行添加、删除、修改、检查。
整体关系如下图所示：
因此，在设计之初，我们需要考虑未来可能在哪些方面进行角色区分，并尽量将其解耦、模块化。 对于技术来说，每个页面模块、每个操作最好采用独立的接口。 对于设计来说，需要保证即使所有角色因权限原因屏蔽了部分操作和数据后，页面和流程仍然能够流畅体验。
在保证初始设计支持后，在配置权限时需要注意以下几点：
(1)判断是否支持前端配置
如果角色和权限比较固定的话，角色和权限的关系一般可以写在后端。 更改需要更改后端并重新上线。 这种情况适用于只有一个用户的系统，例如公司内部系统。
如果需要自定义角色或者不同用户场景下每个角色有不同的权限，则需要在“前端用户配置页面”体现角色的定义以及角色与权限之间的配置。 这种情况适用于自定义角色权限频繁变化的系统和租户系统。
(2) 拆分为基本单元并配置业务逻辑
一般来说，每个对象的“增、删、改、查”都可以看成是一个基本的权限单元。 例如，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为四个权限单元。 在技术和设计上，我们希望尽可能的解耦、模块化。
然而，业务层面的一些操作是集成的。 这些无法分割的权限建议打包成一个整体，在“前端用户配置页面”中提供配置。 例如：如果我们确定系统当前和未来的业务中，只有普通会员具有“人员管理”的查看权限，管理员具有操作权限，那么“增、删、改”这三个基本权限单元就可以合并为“操作”权限进行配置。
(3)页面权限优先于操作和数据权限
必须先配置页面模块权限，才能配置当前页面模块下的具体操作权限以及页面模块的数据显示权限。
(4)查看权限优先于增删改查权限
一般情况下，必须能够查看某个模块或者操作，其他的增删改查才有意义。 因此，设计时应在获取查看权限之前限制其他权限的配置，或者在配置其他权限时默认授予查看权限。
(5)各种角色和权限之间的关系
角色和权限之间的关系不仅仅是简单的“是/否关系”，还包括一定限制的操作和一定程度的数据访问。
以“人事管理”为例：
数据范围：用户有权限查看人员列表，但只能查看所属团队； 数据边界限制（上限等）：最多可添加人员20人等。 数据字段：HR可以查看人员列表中的职级、薪资等字段，其他角色只能查看如如姓名、电子邮件等；
(6)角色和权限的设计表达
在传达系统的权限设计规则时，设计者往往习惯于用最主观、最直接的方式表达想法，比如使用“当……，那么……”的句型。 然而，一个平台涉及到的权限规则有很多。 当整篇文章以这种形式描述时，表达对象就会难以理解。
正确的描述方式：根据开发语言和技术模型的结果进行更清晰的表达。 将每个角色和权限单元绘制成一个网格，在每个交集网格中描述角色和权限的数据关系和限制。
如下所示：
4. 需要注意的提示
1. 隐形管理员
在角色和权限可自定义的系统中，一般需要为系统的初始配置预留一个admin角色，用于添加第一批业务人员并配置基础角色。
有些系统允许上帝视角下admin角色的存在，并且可以在角色配置列表中显示为“超级管理员”。 有些系统不允许这个角色存在，所以可以将这个角色设置为不可见状态，只赋予维护系统的人员。
2. 授予初始权限
对于允许用户自行加入的系统，需要设置一个或多个默认角色，有时可能是只有最基本权限的“访客”角色。
初始权限还可以与用户的一些现有数据字段相关联。 例如，添加用户时，用户的职位是“设计师”角色权限设计，则直接授予“设计师”角色的权限。
3、人事管理中的自我管理
在人员管理中，管理员角色在处理自身问题时需要格外小心。 因为如果修改或删除自己的角色，系统可能没有管理角色，从而无法添加其他成员并正常运行。 您可以在设计时添加判断。 当您是唯一管理角色时，禁止编辑和删除。
4.提示无页面权限
虽然可以通过页面权限限制直接隐藏当前用户无权限的页面，但不排除用户获取权限之外的URL地址。 当用户意外访问未经许可的页面时，必须提供“无权限”提示，防止用户认为系统有bug。
终于
综上所述，整个权限系统设计就是定义各个节点以及节点之间关系的过程。
节点包括：
用户; 用户组； 角色; 角色组； 权限（页面、操作、数据）； 权限组（页面、操作、数据）；
关系包括：
是/否关系； 继承关系； 限制关系（互斥、范围限制、边界限制、场限制……）；...
理清所有逻辑后，通过灵活定义节点，结合节点之间的关系，可以轻松完成100种角色权限设计方案。
作者：姜瑞耀，目标导向交互设计师，负责设计规范、数据平台、任务管理平台等B端产品。设计的目的是解决问题、创新流程，但解决问题、创新的方法流程永远不限于设计。
