B端产品权限设计，别踩了坑才想起我
权限作为一个底层的功能，不仅要考虑用户的实际应用场景，合理划分以适用于不同的角色，还要将其转变为系统的语言。我们表面上看简单的勾选就能达到分权限的目的，但实际上开发在实现的时候没那么简单。
我们都知道，B端用户不是一个个体，是由一群个体构成的组织，那这个组织里面就有不同的岗位，不同的角色，比如说财务、运营、仓库管理员等等。老板作为最高管理者，拥有所有的操作权，但下面的员工，不可能把所有操作权都开放给他。所以权限就应运而生，这也是B端产品中不得不做的一个功能。
权限作为一个底层的功能，不仅要考虑用户的实际应用场景，合理划分以适用于不同的角色，还要将其转变为系统的语言。我们表面上看简单的勾选就能达到分权限的目的，但实际上开发在实现的时候没那么简单。
作为产品经理，前期的规划很重要。
权限的应用
我们先来看看权限在哪些地方应用到，这几个大家应该都不陌生。
1. 版本拆分
从销售层面，我们经常看到，B端产品会分成基础版，专业版等2-3个版本，每个版本包含的功能不同，价格也不同。但我们不可能去开发3个产品，肯定是开发一套最全的版本，然后通过权限去控制功能模块，拆分出不同的版本来。这样既节省了开发成本，也能实现分级销售的目的。
2. 子账号管理
这是针对B端用户内部的账号管理。B端用户在购买系统后，会默认开通一个超级管理员的账号，即拥有所有功能的操作权限，管理员会给下面的员工创建不同的子账号。
比如这是淘宝卖家子账号的设置流程，一些系统可能没有部门结构和分流设置，但是添加员工和修改岗位权限是一定会有的，而且这2个功能是相辅相成的，会同时出现。
为什么不合并成一个功能呢，在创建子账号的时候就直接勾选操作权限？试想，如果创建的子账号数量很多的时候，是不是选择角色会更简单一点？而且从系统上来说，这就是2个独立的模块，要解耦合。
3. 角色管理
这里我们可以看到具体详细的权限点，系统一般会把角色分成2部分，内置角色和自定义角色。
3.1 内置角色
比如上图淘宝卖家的内置角色，系统已经根据商家的特征，分好了客服、运营、美工、财务等常用角色。这些权限都是不可以修改的。对于一般的商家来说，直接使用内置角色就可以很好地给员工进行权限划分了。不仅操作方便，也能给那些不会设置的用户做了个示例。
3.2 自定义角色
如果内置角色不能满足使用，可以自定义角色，可以导入内置角色，在这基础上进行修改，一般都是采用勾选的方式来控制。
权限的设计
我们看上面的图，也能发现权限点的控制不是单一的维度，有交易管理、物流管理这种大模块，也有导出订单、查看详情这种小按钮。
总的来说，权限点的控制会体现在这些方面：模块权限，页面权限，操作权限，字段权限，账号权限。
下面一一来看：
1. 模块权限
我们看到的权限树中的一级菜单，就是属于模块级的，版本拆分就是通过模块权限来控制的，不会再往下细分。
一般来说，模块权限和系统里面的一、二级功能菜单会对应起来。比如下图权限的一级菜单就是导航栏的一级菜单。
我们也可能看到，模块权限点并不在菜单里面，而是藏在系统里的一个比较重要的功能点。
为什么会把他拎出来呢？显得格格不入。
可能是用来拆分版本的重要功能，可能是多个地方共同控制的提炼，也可能是用户很关心的点，方便寻找。所以这块权限提炼会相对复杂一点。
2. 页面权限
模块下一级的权限，就是页面权限了，页面权限是用的最多的。一般来说，重要页面都是有一个权限点的，直接控制这个页面显示或者不显示。
页面权限的设置只需到进入功能的首页即可，通常可能是列表页，比如说订单列表，商品列表。详情页不属于页面权限，因为他是在首页上操作后才进入的，属于按钮/操作权限了。
3. 操作权限
操作权限最多的体现是按钮权限，通过点击等操作来执行业务，最常见的就是增、删、改、查、审核。
这也是用的很多的，我们在设置权限的时候，会看到他们和页面权限放在一起，放在模块权限的下面。
4. 字段权限
字段权限是更细的权限点了，控制这个字段是否可被看到，一般是用来控制页面上的敏感信息的，比如说成本价、供应商信息等。
这个权限用的相对少一点，有的系统会把这个权限点直接做到系统的配置项里面。
5. 账号权限
这个权限用户可能感知不到，他没有放在权限列表中可被勾选。是根据业务的属性做了强行过滤，只能当前账号查看自己的信息。一般来说这种用的不是很多。
比如说医生门诊系统，医生登录系统，只能看自己接诊的患者，不能看到其他医生的，也不能对其他医生的病历、处方等进行修改。这也是为了避免责任纠纷。
还有业绩提成统计报表中也可能会用到，员工可以查看自己的业绩，预算本月工资，但不能看到别人的。
权限设计中的注意事项
虽然权限主要是上面5个层面的划分，看似挺简单的，但实际上在设计的时候，还会有不少的坑，下面这些注意事项一定要注意了哦！
1. 权限点不是越多越好
权限的目的是给不同的人员分工，把这个人用不到的功能模块隐藏掉，或者根据职位的高低，分配流程上的权限等。所以要根据B端业务来定，不要把每个页面、每个按钮都设置上权限。既增加了工作量，也不利于用户选择。
2. 提炼同权限点
有时候一个功能会在系统的好几个功能模块和页面中被用到。如果需要统一控制的话，就把这个功能点提炼出来，作为一个一级权限点。这样用户在选择的时候就能知道，这是一个全局的控制。如果放在某个模块下面，他们可以会误以为只控制这个模块下的内容。
比如说诊疗系统中，快速接诊和转诊的功能，在医生门诊、病人库中都会用到，我们就把他们提炼了出来。
这里面还需注意一个点，开发在做权限控制的时候，往往会把相同的功能点一起做控制。但有时候我们不需要做全局控制，就一定要在文档上注明，这个页面上所有功能都可被使用，不受其他权限点影响。
3. 注意权限点间的相互影响
我们看到一般情况下，有操作权限、字段权限和账号权限的前提是要有页面权限，而有页面权限的前提是要有模块权限。我们必须要告诉用户，权限之间有哪些关联影响。否则用户只勾选了操作权限，但是找不到按钮在哪，以为出bug了呢。
其实上面说的，开发把同功能的权限设置为一个也是权限点间相互影响的一个考虑点，是否有关系，是否需要这种关系，产品经理都要告诉开发和用户。
4. 前端权限展示便于用户理解
开发在做的时候更多考虑的是后台的设计，所以不能直接把开发的结构表展示给用户。我们要按照系统模块、页面的顺序，来排列好，这样用户就能理解，某个权限点具体控制的是哪一项了。
我们看这个权限就比较乱，不知道具体控制的是哪一个页面上的哪一个点。
这个页面的展示就很直观，很容易理解。
5. 不要轻易变更权限
最后再强调一个很重要很重要的点，不要轻易变更权限，因为牵一发而动全身。我们看似只是把一级权限点挪了个位置，变成了二级，或者把二级提成了一级。但这些改动都会涉及到底层，一不小心就出bug了。
如果给一个新系统从0开始设计权限体系，一定要把系统的结构框架定下来，最后再去做权限。如果想到哪做到哪，最后重做的概率很大。
总结
权限不像业务功能那么显眼，就是背后默默支撑的功能，但B端产品却必不可少。
本文分享了权限设计的逻辑和需注意的坑，希望大家在设计权限时，多留个心眼，多思考一点，一定成型，不要来回改动。
如果怕以后做这个功能时找不到这文章了，先收藏下哦！
