在上一篇文章《復盤 | B端產品中，如何構建權限體系》中，筆者講解了：如何在RBAC模型基礎上構建了一套“B端、數據、平臺”產品的權限體系——基于數據集合及角色的權限訪問控制模型。那么，在該模型基礎上，如何針對“權限申請及審批”流程開展交互設計？下文將詳細說明。

在本項目中，產品團隊從長遠考慮，決定將“權限申請及審批”功能在產品內設計成一個完整的閉環，該閉環主要包括“權限申請”及“權限審批”兩個流程，參與的角色有“申請者”、“審批者”及“系統”，各角色定義如下：

• “申請者”，負責發起權限申請；
• “審批者”，負責審批權限申請；
• “系統”，負責判斷業務邏輯和傳遞消息。

各角色之間的串聯關系為：申請者發起申請——系統尋找審批者——審批者進行審批——系統傳遞審批結果給申請者。

據此，進一步可以將“權限申請”及“權限審批”劃分為4個環節：發起、流轉、審批、反饋。

一、權限申請的“發起”

定義“權限申請”的發起用戶為“申請者”，根據上一篇文章中構建的“基于數據集合及角色的權限訪問控制模型”，在本環節，申請者只需要確認兩個信息：數據集合、角色，然后提交權限申請即可。

• 數據集合：選擇需要開通權限的產品，可以多選；
• 角色：選擇需要申請的角色，不同的角色代表不同的權限。

一般的申請者在發起一條權限申請的時候（只可以申請“普通用戶、產品管理員”兩種角色，“平臺管理員、超級管理員”則直接通過后臺配置），由于是使用內部統一的登錄（使用工號），那么TA只需要在界面中確認“數據集合”和“角色”兩個內容，就可以完成權限申請的“發起”。

PS：為了保證能順利通過審核，增加“申請理由”作為必填項。

針對用戶需要申請權限的需求，這里有兩種場景需要討論：

1. 用戶沒有任何數據集合的權限，TA是首次申請

這種場景下，用戶登錄進入產品之后，必然會面臨無任何數據的狀況，所以這個時候需要第一時間提供給他“申請權限”的入口。

2. 用戶已經具備部分數據集合的權限，TA需要繼續申請其他數據集合的權限

這種場景中，可以通過右上角賬號名稱下的菜單，使用“申請權限”功能，這樣可以保證用戶使用產品的過程中，在不中斷當前任務的前提下，可以隨時申請其他數據集合的權限。

二、權限申請的“流轉”

當“申請者”發起一條權限申請的時候，該申請需要流轉至對應的“審批者”——即權限申請的接收用戶，這一過程由系統自動完成。

那么，誰是審批者？

這里就需要給系統定義權限申請的流轉規則：

1. 當用戶在一條“權限申請”中選擇了N個產品時，系統需要將其拆分為N條申請消息并發送至對應的審批者；
2. 當申請的數據集合存在產品管理員時，該申請消息會發送給產品管理員、平臺管理員、超級管理員；
3. 當申請的數據集合沒有產品管理員時，該申請消息會發送給平臺管理員、超級管理員；
4. 當沒有平臺管理員時，該申請消息會發送給超級管理員（超級管理員必須存在）。

三、權限申請的“審批”

當權限申請的消息順利流轉至對應的審批者后，作為“審批者”的用戶會收到一條系統消息。

此時，審批者可以對其進行“審批”。

審批者可以在“消息”內查看權限申請的詳細內容，包括：申請者的姓名、工號、部門、申請產品、申請角色，以及申請理由。

根據申請內容，審批者可以直接操作“通過”或者“駁回”。當操作“通過”后——即表示：給申請者開通對應權限；當操作“駁回”時，需要給出“駁回理由”。

需要注意的是：根據流轉規則，同一條申請消息會存在多個接收者，也就是會有多個“審批者”同時收到相同的權限申請消息。

針對這種情況，規定：當第一個“審批者”操作后，無論是“通過”還是“駁回”，此條申請消息由“待審批”的狀態變更為“已審批”，其他審批者的操作功能隨即失效。

四、審批結果的“反饋”

當審批者完成一條權限申請的審批后，系統會將此條權限申請的結果返回給相應的“申請者”。這時，作為“申請者”的用戶會收到一條系統消息。

申請者可以在“消息”內查看權限申請的結果：

• 如果權限申請已通過，會告知申請者審批者的姓名、工號，以及審批的時間；
• 如果權限申請被駁回，會額外告知駁回理由；
• 如果用戶存在異議，可以通過工號使用其他通訊方式聯系審批者，并與TA溝通。

至此，在產品內形成了“權限申請及審批”的完整閉環。

五、總結

在本項目中，通過“權限申請及審批”的產品閉環設計，為用戶提供了一站式的服務體驗，作為交互設計師，采取的策略可以用6個字總結：“先分解、后聚合”

1. 明確各環節的對象以及TA所面臨的任務；
2. 針對各環節的任務展開分析，將任務拆解為一套流程；
3. 根據各環節的對象和任務，在產品內找出用戶觸點，并以此開展交互設計；
4. 將所有環節進行聚合，形成完成的閉環設計方案。

作者：胡欣欣，公眾號：吹拉彈唱大師（ID：cltcds）

本文由@吹拉彈唱大師 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議