本篇文章中，作者介绍了面向后台系统设计的用户管理三大模块。一个清晰的用户管理系统，可以增强用户在使用系统中的连贯性以及业务的稳定性，权限的清晰设定可以增强系统的安全性，减轻迭代的压力，并减少权限的冗杂和浪费。一起来看看用户管理模块应该如何进行产品设计吧。

登陆模块是用户接触系统的第一触点，尤其是对于C端业务而言若注册流程过程过于冗杂，很容易会造成用户的流失；而对于B端业务来说，注册流程可以是第一步也可以适当忽略，具体需要根据公司内部系统之间的连贯性进行判断，忽略的情况下可以采取直接拉取已验证的账号进行登陆操作，以此基础减少时间的浪费。

01 注册、登陆模块

登陆系统可以分为注册登陆、拉取第三方验证两种登陆方式：

• 拉取第三方验证登陆：登陆无需账户，但需要在第三方或账户管理处有识别账户的统一验证标识比如微软提供的邮箱后缀验证服务，首次登陆时需要在系统后台中找到该用户，并给予用户可访问或其他权限，此时数据库中应存储用户标识信息与权限便于新增权限和记录用户操作记录。
• 注册登陆：用户首次注册登陆时需填写必要信息，此时需要根据业务需求从而判断需要邮箱、手机号等第三方绑定账户。一般情况下是可以通过手机号、微信号、QQ号等直接注册的。

注册流程图：

登陆模块：登录与注册是一个连贯的过程，所以在连接过程中需要做到逻辑流畅便于操作自动跳转等。

登录流程图：

02 用户管理（角色、账户和权限）模块

后台产品的用户权限管理系统可以大致分为三个模块：账户、角色和权限管理；

账户被赋予角色，角色被配置权限，一个账户可以被赋予多种角色，一个角色只能有其对应的权限限制；以此达到拒绝耦合信息冗杂的情况。

1、角色管理

角色是指拥有同一种身份性质的某一类人群的归纳，但角色需要具有继承和约束关系，以此来表明角色有上下级的区别。

在这个模块中，我们需要根据业务来定义出不同的角色名称以及定义相应的角色信息。在业务允许的情况下，尽量不需要将角色设置过多，若存在着角色过多的情况也一定要与角色赋予的权限理清楚。比如：

继承&约束关系

• 角色需要满足继承关系以此表明角色的上下级关系，此部分可以参考决策树根叶子节点来区分角色的父子关系。
• 角色需要满足存在着约束关系，以此来表明角色之间的不同点对应角色下设的权限和业务的不同。
• 先决条件角色：此情况考虑的是系统庞大时，用户在新增一个较高影响范围的角色和权限是否需要满足该角色下的子角色；
• 互斥角色：一个用户只能分配互斥角色组的一种，例如市场专员 、运营人员 、系统管理可以设置为互斥组，一个用户只能归属为其中一组；设置互斥组是处于对系统和业务安全性的考量，比如一个用户的角色是系统管理员的角色若赋予运营角色的权限在误点击的情况下就有可能会影响线上业务。但具体的互斥角色和对应的权限设置需要根据业务的实际情况设定。运行时互斥：一个用户可以拥有多个角色，但在实际业务操作运行中不可同时激活这两个角色以此达成动态职责分离。

角色列表页

• 角色列表页更便于系统管理员进行角色和用户的对应核验，对角色能进行增删改查基础功能外，也可以根据业务实际情况考虑是否新增自定义角色功能等，以此考虑系统的拓展性。
• 列表页 = 展示页 + 一些必要操作的入口；在列表页中可以将主要的信息展示出来比如角色ID、角色名称、权限、创建时间以及操作等；当基本权限和操作权限较多时可以仅展示一部分，剩余部分可以采用【光标移动到此字段时进行全部展示or在操作字段下多加一个查看操作进行详情页的形式】

如下图：

新增角色页

• “新增角色”和“编辑角色”都是给角色赋予相应的定义，但编辑角色需要考虑目前角色的使用情况，在已有的系统使用中是否已经存在并运行，当修改时是否会影响线上系统。赋予新增角色的权限是站在长期价值上考虑系统的可拓展性，在不断迭代的业务中新增业务模块和权限时无需接入新的开发，但同时更需要在一开始就做好相关的定义与新增的规则，所以在最初搭建时期不建议提供新增角色的功能。

  

• 当角色的权限较少时可以采用【下拉框】的形式来选择，当权限较多时可以采用【权限罗列】的形式。

2、权限管理

权限管理部分是逻辑性最强且对于系统全貌影响来说最为广大的，需要提前将角色和对应的权限进行匹配，将权限的名称、描述、性质（基本/操作）等信息梳理清楚，此处需要注意自身是无法给与自身权限的，虽然在一定情况下会造成操作的麻烦但极大的程度上减少了不安全性。

相关权限模型可以参考RBAC：基于角色的访问控制

• RBAC定义：当一个操作，同时满足a与b时，允许操作：a.规定角色可以对哪些资源进行哪些操作 ；b.规定主体拥有哪些角色
• RBAC的思想，来源于现实世界的企业结构。

权限列表页

一个好的权限系统需要能够满足可拓展、高效易维护、层次分层并且可追溯。

• 在做权限梳理之前与业务和开发同学达成一致，确定哪些权限是同类型的、可同组聚合，而哪些业务或功能的权限是必须分开设定的。
• 【权限性质】部分是根据业务情况实际设置的需要规定好角色与【查看】、【操作】等权限的设置，在逻辑整体上需满足角色于权限的对应，从而实现不同角色对应的业务页面查看、编辑、删除等功能的不同操作，甚至同个页面的某些元素的查看、编辑、删除等功能根据角色与权限的对应关系可单独设定。
• 权限设定也可以考虑父子关系

3、账户管理

此功能模块与注册账户的功能模块息息相关。账号管理，是将用户与角色对应起来的模块，一个用户对应一个账户，一个账户可以对应不同的角色，不同的角色被赋予不同的权限就可以达到了【一个账户对应多种权限】账户管理。这一模块，需要设置相应字段，对内部人员的信息进行管理，也是管理员最常用到的功能。

账户列表页

• 列表页 = 展示页+一些必要操作的入口，列表页的主要作用是可以让用户清晰的查询到必要信息，比如用户ID、用户名、部门、角色、账号状态、注册时间以及操作（操作中首先应该具备“编辑”、“删除”基础的操作功能）；
• 另一方面，某些账户可能存在冻结的情况（此情景状态在用户管理账户层级较少但某些业务场景中较为常见），基于此种情况需要新增增加“冻结”和“启用”的功能。
• 除此之外，便于后续的数据分析和操作记录可以前端做一些简单的数据埋点，比如最近登录时间、登录次数等。

新增账户页面

• 当点击“新增账户”按钮时，当前页面可以跳转到填写账号信息的页面，【新增账号】页面的字段要尽可能的罗列出账户所需的信息并且要确定此账户的所对应的角色。由于角色本身是带有权限性质的，所以不需要匹配权限。如下图：

总结

以上介绍的用户管理三大模块是主要面向后台系统设计的，用户也是企业内部人员。一个清晰的用户管理系统可以增强用户在使用系统中的连贯性以及业务的稳定性，权限的清晰设定可以增强系统的安全性，过于繁多的角色和权限不仅会增加迭代的压力也会存在权限的冗杂和浪费。所以在产品设计的开始一定要遵循MVP原则，小步快走。

本文由 @一个七月 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。