写在前面，为什么要写权限系统的设计呢？因为每一个项目，有管理后台，90%会有权限管理。在我自己历史以往的项目，其实对于权限始终是一个相对表面的认知。直到我去年做MFG研究了钉钉的管理系统、以及今年做了土地工重构，让我对权限有了一个深度的认知。
1. 权限是什么
我对于权限的理解，一开始是一个账号，管理着后台的某些模块。这个时候，权限很简单，他是一个账号列表，可以编辑账号信息以及设置账号查看菜单。即账号yimi可以管理订单列表。后面接了一些门店端的项目，在区分菜单查看上，也加上了数据区分，即账号yimi可以管理龙岗店的订单列表数据。上面这两项，我觉得可以基本可以支持30万以上的项目是足够使用的。
然后更深一个层级的，当你接了一个50万以上的项目，你的后台管理员是一个集团的人，或者是上百人。这个时候一个账号区分是远远不能满足的。也延伸了在做MFG的时候研究了钉钉的逻辑，权限不仅仅是开通一个账号(仅有账号+密码)这么简单，权限是对于不同部门的人的管理。那么这个时候会将账号跟菜单权限独立开来。账号即部门下面的某个成员，可通过手机号作为唯一标识。菜单权限按照不同角色去区分，财务有拥有什么菜单、采购拥有哪几个菜单。
听到这里，权限就涉及了：部门、成员、角色、菜单。那我会觉得，权限可复杂可简化，其实无非是人管事。那么不同的权限设计会有什么区别呢？


2. 最小权限设计
最小的权限设计，如下图所示，有登录账号、密码、以及菜单勾选。其实还有个XS版本的，即仅有账号，无菜单权限分隔。

最小权限设计-图示1

那什么情况会使用这种最小的权限设计，我个人的理解是小型的项目，或者说客户内部运营结构相对简单。这个时候需要注意几点，第一个拥有整个菜单即拥有菜单所有操作，第二点是没有数据隔离，即每个拥有菜单权限的管理员查看内容一致。对于需求梳理如下所示：

一级菜单
二级菜单

功能描述

管理员列表
列表

按照创建时间倒序显示；可模糊搜索账号名称；
列表显示账号名称、创建时间；可对列表数据进行编辑/删除的操作。
新增

必填账号名称(仅可以输入英文+数字，不可超过20位字符)、账号密码(仅可输入英文+数字+特殊字符，限制输入6-18位字符)；选择菜单权限，非必填项，可权限所有菜单或者单个勾选。
提交判断：
需要必填项完成填写后，保存按钮高亮可点击；判断是否有重复账号名称，有则吐司提示：改账号名称已存在，请更换；

提交成功后，跳转列表页面并刷新数据显示。
编辑

可编辑所有数据。
删除

点击删除，弹窗提示是否删除，确认后账号进行软删除。


3. 中型项目权限设计

中型大小的项目，类似于多门店、或者是负责角色不同，同个模块需要查看不同数据、进行不同的操作。如下图所示。


中型项目权限设计-编辑管理员-图示2


中型项目权限设计-编辑角色

相对于最小权限设计，你可以理解为菜单+账号的拆分，并且在菜单的基础上，扩展了操作权限。也通过角色的区分，扩展了数据权限。此时的权限=菜单权限+操作权限+数据权限。
相对于上一个会复杂很多，为什么我前面会说建议30万以上的项目，再去做这一套中型的权限系统？一方面，众所周知是由于开发工作量以及难度，对应报价会高；另一方面是，这个的复杂度也提高了他使用难度，如果是没有这种业务情况需求(类似于多门店、或者是负责角色不同)，就不建议用了。最后也是最重要一个方面，就是我曾在一篇《简约至上：交互式设计四策略》的文章中看到，针对不可持续性产品的说明：不断向软件增加功能，是不可持续的。增加复杂性意味着遗留代码越来越沉重，导致产品维护成本越来越高，而且也越来越难以灵活应对市场变化。这个道理我想不仅仅适用于用户前端，对管理后台也同样适用。
对应的需求梳理如下：

一级分类
二级分类

功能描述

管理员列表
列表

按照创建时间倒序显示；可联合模糊搜索账号名称、角色名称、账号姓名；

列表显示账号名称、角色名称、账号姓名、创建时间；可对列表数据进行编辑/禁用/启用/删除的操作。
新增

必填账号名称(仅可以输入英文+数字，不可超过20位字符)、账号密码(仅可输入英文+数字+特殊字符，限制输入6-18位字符)；选择角色名称，非必填项，可单选角色；

选填账号姓名，限制输入5个中文；提交判断：
需要必填项完成填写后，保存按钮高亮可点击；判断是否有重复账号名称，有则吐司提示：改账号名称已存在，请更换；

提交成功后，跳转列表页面并刷新数据显示。
扩展项：

一个管理员可以拥有多个角色，这个时候要注意角色上限，已经角色拥有权限重复的情况。
编辑

可编辑所有数据。
禁用/启用

点击禁用，弹窗提示禁用后管理员无法正常登录；点击启用，弹窗提示启用后管理员恢复正常登录。
删除

点击删除，弹窗提示是否删除，确认后账号进行软删除。
角色列表

列表

按照创建时间倒序显示；可模糊搜索角色名称；
列表显示角色名称、创建时间；可对列表数据进行编辑/删除的操作。
新增

必填角色名称(不可超过20位中文)；选择数据权限(即原型门店权限)，非必填项，可全选；

选择菜单权限+操作权限，非必填项，可全选；提交判断：
需要必填项完成填写后，保存按钮高亮可点击；判断是否有重复角色名称，有则吐司提示：角色名称已存在，请更换；
提交成功后，跳转列表页面并刷新数据显示。
此处的菜单+操作权限，可以用石墨文档或者是在页面上，直接绘制所有菜单，以及对应需要控制的操作按钮

编辑

可编辑所有数据；编辑之后，管理员重新登录获取新的权限。
删除

点击删除，弹窗提示是否删除，确认后账号进行软删除。


4. 大型项目权限设计

大型项目的权限，最大的一个变化，是有部门组织架构，不同部门的人使用系统，即将管理员管理拆解为部门管理+成员管理，但是又不仅仅于此。在一个接入审批的系统、或者CRM中，往往数据是相对独立的，可以按照部门组织架构数，去区分数据的权限。如下图所示


大型项目权限设计-部门组织架构-图示4

如果说，中型项目的数据权限是按照门店或者区域划分，那么部门树则是数据权限的另一个维度。按照创建者所在部门，将这条数据归属于某个成员某个部门(此处还要考虑成员存在多部门的情况)，同个部门间数据独立，而主管可以查看所有人的数据。则这个数据划分，并不适用于后台管理的所有列表，例如用户列表、订单列表此类数据来源并非后台的，或者是一些文案管理的列表，并没有必要做数据的区分。所以在开发的时候，还需要在每个列表列出说明，是否使用。
这个逻辑实现的确是相对比较复杂的，整个权限系统可以相当于一个小型项目了。这个需求着实有点多，放下去有点惊人，我大概写了一下功能点，有需要的小伙伴可以会后问我要。
一级菜单
二级菜单

功能点
人事管理

部门列表

列表、新增、编辑、删除
成员列表

列表、新增、编辑、停用、详情
账号列表

列表、新增、编辑、禁用/启用、详情
权限管理

菜单列表

列表、新增、编辑、禁用/启用、操作管理、详情
主管理员列表

列表、添加、移除
角色列表

列表、新增、编辑、禁用/启用、删除
5. 总结

权限还是一个可简单可复杂的系统模块，但是还是要按照需求，进行定制设计。熟悉客户体系跟需求后，提出的方案才能更贴合、更有说服力，才能真正解决客户的问题。所以也建议，对权限系统感兴趣的话，有空的时候多研究一下钉钉、飞书这类型的软件，大厂的解决方案，每个模块甚至于每个文案内容，都凝聚着一整个技术团队的心血