用户权限管理是平台类产品的基础，怎样设计平台的用户权限对后续的场景和拓展至关重要。本文通过简单的例子总结几点“用户角色权限”设计思路供大家参考。
我是在2016年的一个B端管理项目中第一次接触到用户权限设计，因为当时是测试 需求分析的职责，所以只是把这里面的功能梳理明白，知道怎么用，并没有深入思考。
转岗产品之后，经常会在社群里看到有人问类似于用户管理怎么做，权限设置怎么控之类的问题，这类问题几句话也说不明白。
所以今天把自己对这部分的理解整体梳理出来，既能作为部门新入职同事的培训材料，同时也希望对读到这篇文章的你带来一点帮助。
01 为什么进行用户权限设计？其实用户权限设计对于C端产品也经常遇到，比如普通用户、VIP用户可能看到的功能就不一样，或者同样的页面看到的数据也不一样。不过更广泛的应用还是在B端产品，或者C端产品的管理后台（平台管理端）
我们以B端产品为例，平台提供了200个功能菜单，500个功能按钮，但是使用者的身份不同，或使用目的不同，有的人可能只用到其中的一小部分功能。
或者对于企业来说，不同人员的分工不同，相同部门但不同级别的人员可操作权限不同、可查看的数据不同等等，这些实际的使用场景都最终指向了产品中灵活的、可自定义配置的权限管理功能。
这样说可能比较宽泛，我们代入一个实际的场景（能理解的可以直接跳过看下一小节）。
一家两百人的互联网企业，分为研发部、销售部、财务部、人事部，这家企业采购了一个数字化办公软件。
- 人事部用它对企业的人员信息、招聘信息、员工的入职、转正、调岗、离职等进行管理；
- 财务部用它制定公司的成本预算、记账报账、核算并发放工资、归档发票等；
- 而全体员工也都使用平台进行OA办公，线上流程发起及审批；
- 企业高管则通过平台的各类统计功能监控、查看企业的日常经营数据。
在这个场景中，平台的功能页面可能有几百个，但是针对不同的部门人员，登录之后看到的功能菜单是不尽相同的，或者同一个菜单的操作权限也是有差异的。
- 比如【入职信息查询】页面，hr和行政都能查看，但是hr有【入职】的按钮，行政却没有；
- 比如财务部的财务专员A和B，一个负责研发部预算，一个负责销售部预算，虽然他们都能访问预算功能，但看到的数据也是不一样的；
- 而C作为财务部总监，全公司的预算数据都可以看到。
以上提到的场景都是实际应用中最常见的，我们一起来看看如何进行设计吧
02 用户权限设计的几个关键词我习惯于把权限分为以下几类：
1）页面权限
即功能菜单的权限，以一级菜单->二级菜单->三级菜单->四级菜单的级别依次呈树形排列。勾选上的菜单即可访问，同时被选择菜单的上级也默认被选择（好比没有单元门，你怎么找到家门？）。
2）按钮权限
按钮通常分为“增、删、改、查”四大类，增的类型有很多，涉及的业务面也很广，比如新增员工信息、新增预算信息、新增发票信息等，都属于每个页面权限下的“增”。对于四类操作，一定不是拥有这个页面就一定拥有所有操作权限，因为很多人可能只有查的权限。所以要做好权限控制，一定要做按钮的控制。
以上两部分又可统称为功能权限。
同时我准备了两个常见的功能权限配置样式，抛砖引玉，希望能给你带来一点思路：
方案1
方案2
3）数据权限
最常见的数据控制手段是基于“组织架构树”，组织架构（部门/分支机构）中的上级可以查看本级及下级的所有数据，或者可以指定某个组织的数据。
4）应用权限
这是后续衍伸出来的功能组集合。我们可以把一个功能组抽象为一个应用。比如按照上面的例子，可以把产品内的功能合并成以下几类：包含了人事服务、财务服务、办公服务、假勤服务、数据服务、客户服务等几大应用。我们可以先整体为这家企业赋予某些应用的权限，再在这些应用下为用户分配不同的功能权限。
当然，如果我们把它定义为页面权限中的一级菜单，也是可以的，只不过当平台内的功能越来越多时，一级菜单的个数也会很多，菜单的级别也会很深。所以再单独抽象一个新的功能组概念，不仅从理解上更清晰，看起来也高大上了一些~而且这些功能组后续还能作为增值服务为B端客户设置开通、付费等衍伸场景。
除了权限的分类，为了最终达成设计目标，我们还会引入【角色】的概念。
1）角色
角色是上述几类权限的集合
我所理解角色的设计目标是：为了解耦，为了可批量配置化（具体关系请看第三小节）。
- 比如财务专员角色，包含了10个页面，25个按钮，数据为只能看到研发部；
- 人事专员角色，包含了20个页面，15个按钮，数据为全公司。
2）用户
用户是平台的使用者，用户登录之后能够看到的，能够操作的数据，都来自于我们为这个用户赋予了哪些角色，这些角色中拥有哪些权限。
- 比如张三和李四都是财务专员角色，就可以在10个页面中看到研发部的相关数据，并进行25种操作；
- 比如王五和赵六是人事专员角色，就可以在20个页面中看到全公司的相关数据，并进行15种操作。
当然，如果张三升职了，变成了统管财务和人事的负责人（财务主管），那么我们可以为张三同时赋予两个角色，张三的功能权限和数据权限就变成了这两个角色的“并集”。
（请自觉忽略我的“灵魂画笔”）
03 基本的设计关系通过【角色】将各类权限汇集起来，批量赋予每个【用户】，再通过组织架构将每个用户的数据权限进行筛选。
最终功能权限和数据权限结合，呈现给用户。
组合的方式也有两种，我们可以根据自己产品的实际情况进行选择。
方式1（功能权限 数据权限=角色->用户）
方式2（功能权限->角色 数据权限 =>用户）
无论哪种方式，都可以保证设计的关联性和清晰度，还能在修改时减少操作环节。
比如方式1中，企业现在有10个人拥有财务专员的角色，如果要给财务专员增加15个新的功能，并增加对销售部的数据管理范围，我们只需要针对【财务专员】这个角色进行一次修改即可生效。
04 进阶的设计方法1. 对于企业多级部门的数据权限配置
上面写到的是一些简单的场景，实际应用中，会有很多企业存在多级部门的情况，比如研发部下分为研发一部、研发二部，研发一部又分为产品部、技术部。
对于拥有相同功能权限的张三和李四，在数据权限上张三需要查看研发一部所有数据，而李四只能查看研发一部本级的数据。
所以后期我们可以在数据权限设置时增加对组织架构的设定的三种类型：
2. 初始化角色（预制角色）
用户权限设置完成后，我们还需要考虑新用户的预制角色，我们不能让用户从零开始一点点配置，因为这样不仅费时费力，大部分用户也配不明白，即便平台提供了培训手册或视频，但是又有多少用户会认真看呢？
所以不同的平台对于新入驻的用户，要预制一套相对常规的规则。当然不仅是预制角色，其他的业务功能也需要按需预制，毕竟降低用户的理解难度和操作难度，也是提高入驻率的关键方式。
后续我也会单独整理我们可以采用哪些方法降低B端用户的上手难度和准入门槛，欢迎持续关注~
3. 有些功能需要单独维护访问权限
有些场景不太好通过平台级的设计来解决，建议还是针对具体的场景进行特色化设计。
比如企业的合同管理功能，人事一部只能看到员工的劳务合同，人事二部只能看到员工的保密协议。这种按业务类型区分的数据分类，参照上文的设计模式就不好实现，所以只能在合同管理功能中单独增加以类型区分的数据筛选条件。
05 需要强调的两件事1. 尽量不要把特色化改动直接挂到“用户”上
即便遇到一些偶现的用户权限特殊处理，也尽量采用对角色的新增和配置形成权限集合后，再赋予用户，而不是在用户上直接进行修改。
2. 在最终测试验证环境，一定不要只使用【超级管理员】操作
因为超管一般不会出问题，我们需要使用新维护的角色，代入用户的实际使用场景，对平台的功能进行全流程冒烟测试，在这个过程中才能够发现更多的隐藏问题。
以上就是今天对用户权限的设计总结。
06 写在最后设计思路是一回事，具体的解决方案又是另一回事，希望今天的分享能够为你带来一些帮助。
权限设置在后续的工作中和实际场景连接后，会演变出非常多的可能性，所以需要我们结合自身团队的诉求，产品的目标和现状，和研发人员一起讨论出更合理的设计方案。
作者：不想延期，公众号：不想延期
本文由 @不想延期 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
,
