账号管理系统(账号管理app)

本文介绍了后台系统设计中用户管理的三个模块。清晰的用户管理体系可以增强用户使用系统的一致性和业务稳定性,权限的清晰设置可以增强系统的安全性,减少迭代的压力,减少

本文介绍了后台系统设计中用户管理的三个模块。清晰的用户管理体系可以增强用户使用系统的一致性和业务稳定性,权限的清晰设置可以增强系统的安全性,减少迭代的压力,减少权限的杂乱和浪费。我们来看看用户管理模块应该如何设计产品。

账号管理系统(账号管理app)

登录模块是用户接触系统的第一接触点,尤其是C端服务,如果注册流程过于复杂,很容易导致用户流失;对于B端业务,注册流程可以是第一步,也可以适当忽略,需要根据公司内部系统之间的连贯性来判断。如果忽略,可以直接拉验证过的账号登录,减少时间浪费。

01 注册、登陆模块

登录系统分为注册登录和第三方验证两种登录方式:

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

登录模块:登录和注册是一个连贯的过程,所以在连接过程中要有逻辑性,容易自动跳转。

登录流程图:

用户管理(角色、账号、权限)模块后台产品的用户权限管理系统大致可以分为三个模块:账号、角色、权限管理;

为帐户分配角色,并为角色配置权限。一个账户可以被赋予多个角色,一个角色只能有其对应的权限限制。这样就可以拒绝耦合信息冗杂的情况。

1.角色管理角色是指对同一身份的某一群人的诱导,但角色需要有继承和约束关系,以此来表明角色有上下级之分。

在该模块中,我们需要定义不同的角色名称,并根据业务定义相应的角色信息。如果业务允许,尽量不用设置太多角色。如果角色太多,一定要明确角色赋予的权限。例如:

继承和约束关系

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

角色列表页面

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

如下图:

添加角色页面

“新增角色”和“编辑角色”都是给角色赋予相应的定义,但编辑角色需要考虑目前角色的使用情况,在已有的系统使用中是否已经存在并运行,当修改时是否会影响线上系统。赋予新增角色的权限是站在长期价值上考虑系统的可拓展性,在不断迭代的业务中新增业务模块和权限时无需接入新的开发,但同时更需要在一开始就做好相关的定义与新增的规则,所以在最初搭建时期不建议提供新增角色的功能。当角色的权限较少时可以采用【下拉框】的形式来选择,当权限较多时可以采用【权限罗列】的形式。2.权限管理权限管理部分的逻辑性最强,对系统的整体画面影响也最广泛。需要提前将角色与相应的权限进行匹配,并对权限的名称、描述、性质(基本/操作)等信息进行梳理。这里需要注意的是,不能给自己许可。虽然在某些情况下会造成操作上的麻烦,但是会大大降低不安全感。

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

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

许可权列表页面

一个好的授权系统应该是可扩展的、高效的、易于维护的、分层的和可追踪的。

在做权限梳理之前与业务和开发同学达成一致,确定哪些权限是同类型的、可同组聚合,而哪些业务或功能的权限是必须分开设定的。【权限性质】部分是根据业务情况实际设置的需要规定好角色与【查看】、【操作】等权限的设置,在逻辑整体上需满足角色于权限的对应,从而实现不同角色对应的业务页面查看、编辑、删除等功能的不同操作,甚至同个页面的某些元素的查看、编辑、删除等功能根据角色与权限的对应关系可单独设定。权限设定也可以考虑父子关系3.账户管理该功能模块与注册账户功能模块密切相关。帐户管理是一个将用户与角色相关联的模块。一个用户对应一个账号,一个账号可以对应不同的角色。不同的角色可以被赋予不同的权限来实现账户管理。该模块需要设置相应的字段来管理内部人员的信息,这也是管理员最常用的功能。

帐户列表页面

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

当点击“新增账户”按钮时,当前页面可以跳转到填写账号信息的页面,【新增账号】页面的字段要尽可能的罗列出账户所需的信息并且要确定此账户的所对应的角色。由于角色本身是带有权限性质的,所以不需要匹配权限。如下图:综上所述,以上介绍的用户管理三大模块主要是针对后台系统设计的,用户也是企业内部人员。清晰的用户管理系统可以增强用户使用系统的一致性和业务的稳定性,权限的清晰设置可以增强系统的安全性。过多的角色和权限不仅会增加迭代的压力,还会造成权限的杂乱和浪费。所以在产品设计之初,一定要遵循MVP原则,小步快走。

本文最初由@于7月发表中中中中中中中。每个人都是产品经理。未经许可,禁止复制。

来自Unsplash的图像,基于CC0协议。

此观点仅代表作者本人,大家都是产品经理。平台只提供信息存储空服务。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。

作者:美站资讯,如若转载,请注明出处:https://www.meizw.com/n/391883.html

发表回复

登录后才能评论