交互设计先分解后聚合权限申请及审批的产品闭环

　　在上一篇文章《复盘 | B端产品中，如何构建权限体系》中，笔者讲解了：如何在RBAC模型基础上构建了一套＂B端、数据、平台＂产品的权限体系——基于数据集合及角色的权限访问控制模型。那么，在该模型基础上，如何针对＂权限申请及审批＂流程开展交互设计？下文将详细说明。
　　在本项目中，产品团队从长远考虑，决定将＂权限申请及审批＂功能在产品内设计成一个完整的闭环，该闭环主要包括＂权限申请＂及＂权限审批＂两个流程，参与的角色有＂申请者＂、＂审批者＂及＂系统＂，各角色定义如下：
　　＂申请者＂，负责发起权限申请；
　　＂审批者＂，负责审批权限申请；
　　＂系统＂，负责判断业务逻辑和传递消息。
　　各角色之间的串联关系为：申请者发起申请——系统寻找审批者——审批者进行审批——系统传递审批结果给申请者。
　　据此，进一步可以将＂权限申请＂及＂权限审批＂划分为4个环节：发起、流转、审批、反馈。
　　一、权限申请的＂发起＂
　　定义＂权限申请＂的发起用户为＂申请者＂，根据上一篇文章中构建的＂基于数据集合及角色的权限访问控制模型＂，在本环节，申请者只需要确认两个信息：数据集合、角色，然后提交权限申请即可。
　　数据集合：选择需要开通权限的产品，可以多选；
　　角色：选择需要申请的角色，不同的角色代表不同的权限。
　　一般的申请者在发起一条权限申请的时候（只可以申请＂普通用户、产品管理员＂两种角色，＂平台管理员、超级管理员＂则直接通过后台配置），由于是使用内部统一的登录（使用工号），那么TA只需要在界面中确认＂数据集合＂和＂角色＂两个内容，就可以完成权限申请的＂发起＂。
　　PS：为了保证能顺利通过审核，增加＂申请理由＂作为必填项。
　　针对用户需要申请权限的需求，这里有两种场景需要讨论：
　　1. 用户没有任何数据集合的权限，TA是首次申请
　　这种场景下，用户登录进入产品之后，必然会面临无任何数据的状况，所以这个时候需要第一时间提供给他＂申请权限＂的入口。
　　2. 用户已经具备部分数据集合的权限，TA需要继续申请其他数据集合的权限
　　这种场景中，可以通过右上角账号名称下的菜单，使用＂申请权限＂功能，这样可以保证用户使用产品的过程中，在不中断当前任务的前提下，可以随时申请其他数据集合的权限。
　　二、权限申请的＂流转＂
　　当＂申请者＂发起一条权限申请的时候，该申请需要流转至对应的＂审批者＂——即权限申请的接收用户，这一过程由系统自动完成。
　　那么，谁是审批者？
　　这里就需要给系统定义权限申请的流转规则：
　　当用户在一条＂权限申请＂中选择了N个产品时，系统需要将其拆分为N条申请消息并发送至对应的审批者；
　　当申请的数据集合存在产品管理员时，该申请消息会发送给产品管理员、平台管理员、超级管理员；
　　当申请的数据集合没有产品管理员时，该申请消息会发送给平台管理员、超级管理员；
　　当没有平台管理员时，该申请消息会发送给超级管理员（超级管理员必须存在）。
　　三、权限申请的＂审批＂
　　当权限申请的消息顺利流转至对应的审批者后，作为＂审批者＂的用户会收到一条系统消息。
　　此时，审批者可以对其进行＂审批＂。
　　审批者可以在＂消息＂内查看权限申请的详细内容，包括：申请者的姓名、工号、部门、申请产品、申请角色，以及申请理由。
　　根据申请内容，审批者可以直接操作＂通过＂或者＂驳回＂。当操作＂通过＂后——即表示：给申请者开通对应权限；当操作＂驳回＂时，需要给出＂驳回理由＂。
　　需要注意的是：根据流转规则，同一条申请消息会存在多个接收者，也就是会有多个＂审批者＂同时收到相同的权限申请消息。
　　针对这种情况，规定：当第一个＂审批者＂操作后，无论是＂通过＂还是＂驳回＂，此条申请消息由＂待审批＂的状态变更为＂已审批＂，其他审批者的操作功能随即失效。
　　四、审批结果的＂反馈＂
　　当审批者完成一条权限申请的审批后，系统会将此条权限申请的结果返回给相应的＂申请者＂。这时，作为＂申请者＂的用户会收到一条系统消息。
　　申请者可以在＂消息＂内查看权限申请的结果：
　　如果权限申请已通过，会告知申请者审批者的姓名、工号，以及审批的时间；
　　如果权限申请被驳回，会额外告知驳回理由；
　　如果用户存在异议，可以通过工号使用其他通讯方式联系审批者，并与TA沟通。
　　至此，在产品内形成了＂权限申请及审批＂的完整闭环。
　　五、总结
　　在本项目中，通过＂权限申请及审批＂的产品闭环设计，为用户提供了一站式的服务体验，作为交互设计师，采取的策略可以用6个字总结：＂先分解、后聚合＂
　　明确各环节的对象以及TA所面临的任务；
　　针对各环节的任务展开分析，将任务拆解为一套流程；
　　根据各环节的对象和任务，在产品内找出用户触点，并以此开展交互设计；
　　将所有环节进行聚合，形成完成的闭环设计方案。