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