delphi7 增加管理员权限_交互设计 | 先分解后聚合,“权限申请及审批”的产品闭环...

在上一篇文章中,

吹拉弹唱大师:实战复盘,如何构建B端产品的“权限体系”​zhuanlan.zhihu.com

笔者讲解了:如何在RBAC模型基础上构建了一套“B端、数据、平台”产品的权限体系——基于数据集合及角色的权限访问控制模型。那么,在该模型基础上,如何针对“权限申请及审批”流程开展交互设计?下文将详细说明。

前言

在本项目中,产品团队从长远考虑,决定将“权限申请及审批”功能在产品内设计成一个完整的闭环,该闭环主要包括“权限申请”及“权限审批”两个流程,参与的角色有“申请者”、“审批者”及“系统”,各角色定义如下:

  • “申请者”,负责发起权限申请;
  • “审批者”,负责审批权限申请;
  • “系统”,负责判断业务逻辑和传递消息。

各角色之间的串联关系为:申请者发起申请——系统寻找审批者——审批者进行审批——系统传递审批结果给申请者。

据此,进一步可以将“权限申请”及“权限审批”划分为4个环节:发起、流转、审批、反馈。

deb602df46a0703c819a68ca5f0c0419.png

一、权限申请的“发起”

f0b337db13e27de6c28fe5186e7d7317.png

定义“权限申请”的发起用户为“申请者”,根据上一篇文章中构建的“基于数据集合及角色的权限访问控制模型”,在本环节,申请者只需要确认两个信息:数据集合、角色,然后提交权限申请即可。

  • 数据集合:选择需要开通权限的产品,可以多选;
  • 角色:选择需要申请的角色,不同的角色代表不同的权限。

一般的申请者在发起一条权限申请的时候(只可以申请“普通用户、产品管理员”两种角色,“平台管理员、超级管理员”则直接通过后台配置),由于是使用内部统一的登录(使用工号),那么TA只需要在界面中确认“数据集合”和“角色”两个内容,就可以完成权限申请的“发起”。

PS:为了保证能顺利通过审核,增加“申请理由”作为必填项。

bf68887556c903fa7f71e76b858953ed.png

针对用户需要申请权限的需求,这里有两种场景需要讨论:

1. 用户没有任何数据集合的权限,TA是首次申请

这种场景下,用户登录进入产品之后,必然会面临无任何数据的状况,所以这个时候需要第一时间提供给他“申请权限”的入口。

18304278a3bc8e8cdc43759b2b6fef8c.png

2. 用户已经具备部分数据集合的权限,TA需要继续申请其他数据集合的权限

这种场景中,可以通过右上角账号名称下的菜单,使用“申请权限”功能,这样可以保证用户使用产品的过程中,在不中断当前任务的前提下,可以随时申请其他数据集合的权限。

218d4959562c2baedd97508dcc69c430.png

二、权限申请的“流转”

8971734518aac91d58d93576e05bab6c.png

当“申请者”发起一条权限申请的时候,该申请需要流转至对应的“审批者”——即权限申请的接收用户,这一过程由系统自动完成。

那么,谁是审批者?

这里就需要给系统定义权限申请的流转规则:

  1. 当用户在一条“权限申请”中选择了N个产品时,系统需要将其拆分为N条申请消息并发送至对应的审批者;
  2. 当申请的数据集合存在产品管理员时,该申请消息会发送给产品管理员、平台管理员、超级管理员;
  3. 当申请的数据集合没有产品管理员时,该申请消息会发送给平台管理员、超级管理员;
  4. 当没有平台管理员时,该申请消息会发送给超级管理员(超级管理员必须存在)。

三、权限申请的“审批”

a980ac8e767ff82bc50d0b9b4c89452b.png

当权限申请的消息顺利流转至对应的审批者后,作为“审批者”的用户会收到一条系统消息。

2ebc62a5d504d826f257b38b0573d8a4.png

此时,审批者可以对其进行“审批”。

审批者可以在“消息”内查看权限申请的详细内容,包括:申请者的姓名、工号、部门、申请产品、申请角色,以及申请理由。

d562a5f0a26da9a6a5e3a243ed4d5a39.png

根据申请内容,审批者可以直接操作“通过”或者“驳回”。当操作“通过”后——即表示:给申请者开通对应权限;当操作“驳回”时,需要给出“驳回理由”。

902a14aa43f9719aed92e91ca90c706a.png

需要注意的是:根据流转规则,同一条申请消息会存在多个接收者,也就是会有多个“审批者”同时收到相同的权限申请消息。

针对这种情况,规定:当第一个“审批者”操作后,无论是“通过”还是“驳回”,此条申请消息由“待审批”的状态变更为“已审批”,其他审批者的操作功能随即失效。

四、审批结果的“反馈”

bdb655ca0c54e2ecde17ac2a3c001f1c.png

当审批者完成一条权限申请的审批后,系统会将此条权限申请的结果返回给相应的“申请者”。这时,作为“申请者”的用户会收到一条系统消息。

9e9ec940c9207ad48f6bce45376b3021.png

申请者可以在“消息”内查看权限申请的结果:

  • 如果权限申请已通过,会告知申请者审批者的姓名、工号,以及审批的时间;
  • 如果权限申请被驳回,会额外告知驳回理由;
  • 如果用户存在异议,可以通过工号使用其他通讯方式联系审批者,并与TA沟通。

74587b1db442e107c605c1d8ce53f999.png

至此,在产品内形成了“权限申请及审批”的完整闭环。

五、总结

在本项目中,通过“权限申请及审批”的产品闭环设计,为用户提供了一站式的服务体验,作为交互设计师,采取的策略可以用6个字总结:“先分解、后聚合”

  1. 明确各环节的对象以及TA所面临的任务;
  2. 针对各环节的任务展开分析,将任务拆解为一套流程;
  3. 根据各环节的对象和任务,在产品内找出用户触点,并以此开展交互设计;
  4. 将所有环节进行聚合,形成完成的闭环设计方案。

作者:胡欣欣,公众号:吹拉弹唱大师(ID:cltcds)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值