設計實例:如何以“權限”為單位的進行權限設計(二)
上篇文章介紹了以“用戶”為單位的權限設計,今天就如何以“權限”為單位進行權限設計為大家展開介紹。
在上一篇文章中,我們說到了以“用戶”為單位的權限設計,適用的業務場景為:適用該系統的人之中,存在很多擁有同一類權限的人。
當使用該系統的人中,當非常多的人的權限不一樣時,那么以“用戶”為單位的權限設計就不適用了,這時候我們需要用到以“權限”為單位的權限設計。
以“權限”為單位的權限設計
適用的業務場景
當使用該系統的人之中,很多人的權限是不一樣的,那么我們需要針對單一權限進行單一的設置,這樣才能方便進行統一管理設置。
舉例:在一個審核系統中,擁有三級審核權限、二級審核權限、一級審核權限的人是不一樣的,那么我們需要針對權限進行選擇人,來進行添加設置。
如何進行設計?
1、信息架構圖
用戶:添加用戶過程中,直接針對用戶設置一個單一的權限
部門:添加部門時,填寫部門基本資料即可
2、業務流程圖
具體流程:添加用戶時,除基本資料外,需要對用戶設置權限,而添加部門時,填完基本資料即可。
3、具體原型圖設計
菜單有哪些?
除去部門與管理員菜單,增加權限列表的菜單,便于管理,在之后的詳情會說到這一點。
管理員添加
添加用戶時,填充基本資料后,直接設置權限。
部門添加
添加部門,填寫基本資料即可。
權限列表
左方是權限列表,右方為擁有該權限的用戶。
交互方式:鼠標移到用戶名上時,出現“X”,左鍵單擊進行刪除,點擊添加管理員,出現彈窗,進行搜索管理員,可多選,為該權限添加管理員。
涉及到的點:當添加一個新用戶時,針對新用戶設置的權限進行提交后,該權限列表進行更新,權限對應的管理員需要添加該新用戶,保持數據的統一。
為什么不直接在權限列表針對用戶添加權限?
當涉及到添加新用戶的業務場景時,不能在權限列表,一個一個權限地添加,效率太低。
為什么需要權限列表,難道不可以直接在用戶資料中進行修改權限么?
當后臺系統上線了一個新功能,需要對該功能設置權限,眾多用戶需要添加該用戶權限,顯然我一個一個去找用戶修改權限的做法十分低效,那么針對權限,一次性添加眾多用戶,進行多選,可以解決此問題。
以“用戶”與“權限”結合的權限設計
最后一種為以“用戶”與“權限”結合的權限設計,任何業務場景都適用,主要的方法是:將通用的權限(指的是所有的用戶擁有的權限)以及少部分人擁有的權限進行區分,分為兩部分進行管理。
但是此方法的難點在于,如何區分通用權限以及少部分擁有的權限,這個界限純粹憑人工去判斷,一旦判斷失誤,那么此種方案的設計會有很大的問題。
總結
關于權限設計的三種方式已經剖析清楚。
目前業內最通用的還是第一種方式——針對“用戶”為單位的權限設計方式,因為這符合當下大部分公司的組織架構。
而第二種權限設計方式——針對“權限”為單位的權限設計方式,這在政府機關高級機密系統中,更為適用,因為大多數人的權限是不一樣的,更適用于此種方式。
最后一種,目前市場上的產品,此種方式是極少的,能走通,但可能并不是很適用。
其實,權限設計的方式,任何一種邏輯都能走通,最為關鍵的是我們需要根據用戶使用該系統的業務場景去考慮問題,從而得出一個最優解,這是作為一個產品經理應有的思考方式。
相關閱讀
#專欄作家#
不羈,微信公眾號:fuckpm,人人都是產品經理專欄作家,對于電商以及社交領域產品有深入了解,重業務邏輯,喜深入思考,歡迎交流~
本文原創發布于人人都是產品經理,未經許可,不得轉載。
在部門多,成員多的情況下,每次新來一個人或者是變更一次人事,我都要為該用戶重新選擇一次權限……這效率會太低了吧
現在最常用的難道不是RBAC模型?
同問
erp產品多用的第三種,因為erp的主體就是業務邏輯、組織架構和權限系統,但是使用erp軟件的公司卻不固定,所以需要多種方式去管理權限系統。比如SAP
我在創建新用戶的時候,在權限列表里面已經選擇權限;為什么還要權限管理員去添加該用戶,難道這個不能同步嗎?
創建新用戶的時候,進行設置權限,當設置權限成功時,那么權限列表頁中,也會進行更新同步,以保持一致~