全栈工程师?
嗯.....目前并不是!

交互設計 | 先分解后聚合,“權限申請及審批”的產品閉環

在上一篇文章《復盤 | 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)

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《交互設計 | 先分解后聚合,“權限申請及審批”的產品閉環》
文章链接:https://www.pmbear.com/%e4%ba%a4%e4%ba%92%e8%a8%ad%e8%a8%88-%e5%85%88%e5%88%86%e8%a7%a3%e5%90%8e%e8%81%9a%e5%90%88%ef%bc%8c%e6%ac%8a%e9%99%90%e7%94%b3%e8%ab%8b%e5%8f%8a%e5%af%a9%e6%89%b9%e7%9a%84/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们