交互設計 | 先分解后聚合,“權限申請及審批”的產品閉環
在上一篇文章《復盤 | B端產品中,如何構建權限體系》中,筆者講解了:如何在RBAC模型基礎上構建了一套“B端、數據、平臺”產品的權限體系——基于數據集合及角色的權限訪問控制模型。那么,在該模型基礎上,如何針對“權限申請及審批”流程開展交互設計?下文將詳細說明。
在本項目中,產品團隊從長遠考慮,決定將“權限申請及審批”功能在產品內設計成一個完整的閉環,該閉環主要包括“權限申請”及“權限審批”兩個流程,參與的角色有“申請者”、“審批者”及“系統”,各角色定義如下:
- “申請者”,負責發起權限申請;
- “審批者”,負責審批權限申請;
- “系統”,負責判斷業務邏輯和傳遞消息。
各角色之間的串聯關系為:申請者發起申請——系統尋找審批者——審批者進行審批——系統傳遞審批結果給申請者。
據此,進一步可以將“權限申請”及“權限審批”劃分為4個環節:發起、流轉、審批、反饋。
一、權限申請的“發起”
定義“權限申請”的發起用戶為“申請者”,根據上一篇文章中構建的“基于數據集合及角色的權限訪問控制模型”,在本環節,申請者只需要確認兩個信息:數據集合、角色,然后提交權限申請即可。
- 數據集合:選擇需要開通權限的產品,可以多選;
- 角色:選擇需要申請的角色,不同的角色代表不同的權限。
一般的申請者在發起一條權限申請的時候(只可以申請“普通用戶、產品管理員”兩種角色,“平臺管理員、超級管理員”則直接通過后臺配置),由于是使用內部統一的登錄(使用工號),那么TA只需要在界面中確認“數據集合”和“角色”兩個內容,就可以完成權限申請的“發起”。
PS:為了保證能順利通過審核,增加“申請理由”作為必填項。
針對用戶需要申請權限的需求,這里有兩種場景需要討論:
1. 用戶沒有任何數據集合的權限,TA是首次申請
這種場景下,用戶登錄進入產品之后,必然會面臨無任何數據的狀況,所以這個時候需要第一時間提供給他“申請權限”的入口。
2. 用戶已經具備部分數據集合的權限,TA需要繼續申請其他數據集合的權限
這種場景中,可以通過右上角賬號名稱下的菜單,使用“申請權限”功能,這樣可以保證用戶使用產品的過程中,在不中斷當前任務的前提下,可以隨時申請其他數據集合的權限。
二、權限申請的“流轉”
當“申請者”發起一條權限申請的時候,該申請需要流轉至對應的“審批者”——即權限申請的接收用戶,這一過程由系統自動完成。
那么,誰是審批者?
這里就需要給系統定義權限申請的流轉規則:
- 當用戶在一條“權限申請”中選擇了N個產品時,系統需要將其拆分為N條申請消息并發送至對應的審批者;
- 當申請的數據集合存在產品管理員時,該申請消息會發送給產品管理員、平臺管理員、超級管理員;
- 當申請的數據集合沒有產品管理員時,該申請消息會發送給平臺管理員、超級管理員;
- 當沒有平臺管理員時,該申請消息會發送給超級管理員(超級管理員必須存在)。
三、權限申請的“審批”
當權限申請的消息順利流轉至對應的審批者后,作為“審批者”的用戶會收到一條系統消息。
此時,審批者可以對其進行“審批”。
審批者可以在“消息”內查看權限申請的詳細內容,包括:申請者的姓名、工號、部門、申請產品、申請角色,以及申請理由。
根據申請內容,審批者可以直接操作“通過”或者“駁回”。當操作“通過”后——即表示:給申請者開通對應權限;當操作“駁回”時,需要給出“駁回理由”。
需要注意的是:根據流轉規則,同一條申請消息會存在多個接收者,也就是會有多個“審批者”同時收到相同的權限申請消息。
針對這種情況,規定:當第一個“審批者”操作后,無論是“通過”還是“駁回”,此條申請消息由“待審批”的狀態變更為“已審批”,其他審批者的操作功能隨即失效。
四、審批結果的“反饋”
當審批者完成一條權限申請的審批后,系統會將此條權限申請的結果返回給相應的“申請者”。這時,作為“申請者”的用戶會收到一條系統消息。
申請者可以在“消息”內查看權限申請的結果:
- 如果權限申請已通過,會告知申請者審批者的姓名、工號,以及審批的時間;
- 如果權限申請被駁回,會額外告知駁回理由;
- 如果用戶存在異議,可以通過工號使用其他通訊方式聯系審批者,并與TA溝通。
至此,在產品內形成了“權限申請及審批”的完整閉環。
五、總結
在本項目中,通過“權限申請及審批”的產品閉環設計,為用戶提供了一站式的服務體驗,作為交互設計師,采取的策略可以用6個字總結:“先分解、后聚合”
- 明確各環節的對象以及TA所面臨的任務;
- 針對各環節的任務展開分析,將任務拆解為一套流程;
- 根據各環節的對象和任務,在產品內找出用戶觸點,并以此開展交互設計;
- 將所有環節進行聚合,形成完成的閉環設計方案。
作者:胡欣欣,公眾號:吹拉彈唱大師(ID:cltcds)
本文由@吹拉彈唱大師 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議
大佬,審批者那個地方加一個先后順序會不會權責更清晰,另外不用每一個申請都要給平臺管理員吧,是不是可以中間角色審批即可
厲害啊 就是要看到這樣的關于權限論述的文章 收藏了
案例+拆解式的分享。辛苦作者。產品的前端交互效果,以怎樣的形式對接設計及開發人員效果更好呢
我給開發澄清需求的時候,首先會按照流程圖講解一遍,讓開發理解產品設計的思路,然后再結合交互稿講解,什么環節需要什么數據、哪些接口。