2023年产品设计 - 浅谈B端产品用户权限

产品设计|浅谈B端产品用户权限我是在2022年的一个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.在最终测试验证环境，肯定不要只使用【超级管理员】操作

由于超管一般不会出问题，我们需要使用新维护的角色，代入用户的实际使用场景，对平台的功能进行全流程冒烟测试，在这个