設計實例:如何以“權限”為單位的進行權限設計(二)

6 評論 22432 瀏覽 105 收藏 7 分鐘

上篇文章介紹了以“用戶”為單位的權限設計,今天就如何以“權限”為單位進行權限設計為大家展開介紹。

在上一篇文章中,我們說到了以“用戶”為單位的權限設計,適用的業務場景為:適用該系統的人之中,存在很多擁有同一類權限的人。

當使用該系統的人中,當非常多的人的權限不一樣時,那么以“用戶”為單位的權限設計就不適用了,這時候我們需要用到以“權限”為單位的權限設計。

以“權限”為單位的權限設計

適用的業務場景

當使用該系統的人之中,很多人的權限是不一樣的,那么我們需要針對單一權限進行單一的設置,這樣才能方便進行統一管理設置。

舉例:在一個審核系統中,擁有三級審核權限、二級審核權限、一級審核權限的人是不一樣的,那么我們需要針對權限進行選擇人,來進行添加設置。

如何進行設計?

1、信息架構圖

用戶:添加用戶過程中,直接針對用戶設置一個單一的權限

部門:添加部門時,填寫部門基本資料即可

2、業務流程圖

具體流程:添加用戶時,除基本資料外,需要對用戶設置權限,而添加部門時,填完基本資料即可。

3、具體原型圖設計

菜單有哪些?

除去部門與管理員菜單,增加權限列表的菜單,便于管理,在之后的詳情會說到這一點。

管理員添加

添加用戶時,填充基本資料后,直接設置權限。

部門添加

添加部門,填寫基本資料即可。

權限列表

左方是權限列表,右方為擁有該權限的用戶。

交互方式:鼠標移到用戶名上時,出現“X”,左鍵單擊進行刪除,點擊添加管理員,出現彈窗,進行搜索管理員,可多選,為該權限添加管理員。

涉及到的點:當添加一個新用戶時,針對新用戶設置的權限進行提交后,該權限列表進行更新,權限對應的管理員需要添加該新用戶,保持數據的統一。

為什么不直接在權限列表針對用戶添加權限?

當涉及到添加新用戶的業務場景時,不能在權限列表,一個一個權限地添加,效率太低。

為什么需要權限列表,難道不可以直接在用戶資料中進行修改權限么?

當后臺系統上線了一個新功能,需要對該功能設置權限,眾多用戶需要添加該用戶權限,顯然我一個一個去找用戶修改權限的做法十分低效,那么針對權限,一次性添加眾多用戶,進行多選,可以解決此問題。

以“用戶”與“權限”結合的權限設計

最后一種為以“用戶”與“權限”結合的權限設計,任何業務場景都適用,主要的方法是:將通用的權限(指的是所有的用戶擁有的權限)以及少部分人擁有的權限進行區分,分為兩部分進行管理。

但是此方法的難點在于,如何區分通用權限以及少部分擁有的權限,這個界限純粹憑人工去判斷,一旦判斷失誤,那么此種方案的設計會有很大的問題。

總結

關于權限設計的三種方式已經剖析清楚。

目前業內最通用的還是第一種方式——針對“用戶”為單位的權限設計方式,因為這符合當下大部分公司的組織架構。

而第二種權限設計方式——針對“權限”為單位的權限設計方式,這在政府機關高級機密系統中,更為適用,因為大多數人的權限是不一樣的,更適用于此種方式。

最后一種,目前市場上的產品,此種方式是極少的,能走通,但可能并不是很適用。

其實,權限設計的方式,任何一種邏輯都能走通,最為關鍵的是我們需要根據用戶使用該系統的業務場景去考慮問題,從而得出一個最優解,這是作為一個產品經理應有的思考方式。

相關閱讀

設計實例:如何以“用戶”為單位的進行權限設計(一)

#專欄作家#

不羈,微信公眾號:fuckpm,人人都是產品經理專欄作家,對于電商以及社交領域產品有深入了解,重業務邏輯,喜深入思考,歡迎交流~

本文原創發布于人人都是產品經理,未經許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 在部門多,成員多的情況下,每次新來一個人或者是變更一次人事,我都要為該用戶重新選擇一次權限……這效率會太低了吧

    來自浙江 回復
  2. 現在最常用的難道不是RBAC模型?

    來自北京 回復
    1. 同問

      來自浙江 回復
  3. erp產品多用的第三種,因為erp的主體就是業務邏輯、組織架構和權限系統,但是使用erp軟件的公司卻不固定,所以需要多種方式去管理權限系統。比如SAP

    來自江蘇 回復
  4. 我在創建新用戶的時候,在權限列表里面已經選擇權限;為什么還要權限管理員去添加該用戶,難道這個不能同步嗎?

    來自浙江 回復
    1. 創建新用戶的時候,進行設置權限,當設置權限成功時,那么權限列表頁中,也會進行更新同步,以保持一致~

      來自廣東 回復