小男

設計師有時會對角色權限系統有一絲畏難情緒。一方面因為角色權限系統的配置作為一個非常后臺的管理功能,在競品調研過程中很難通過上帝視角去解剖其中邏輯,自己琢磨又較難透徹;另一方面對于角色權限系統,做好了并不能代表設計能力有多優秀,但一旦沒做好就會導致整個流程不通、產品崩潰。所以設計師常對權限系統望而卻步。以下就筆者的幾次權限設計經歷,提供一些所謂的經驗套路,希望各位設計師從此微笑迎接權限需求。

 

一、令人頭疼的權限設計

設計師在進行設計時,常常會抽象出對產品有訴求的多個角色,再依據角色的特性去梳理使用場景并設計。

當角色之間的使用場景不沖突,不需要隔離時,我們會綜合考慮這些角色的使用場景來設計解決方案:比如網易云音樂同時為需要聽歌和聽電臺的用戶提供所有的功能;

 

當這些角色的使用場景完全不重疊、流程對立時,我們會設計完全獨立的兩套系統,如滴滴的司機端和乘客端;

 

但除了以上兩種情況,在大多數B端產品中,基于流程公正性、信息安全性等因素考慮,各個角色的使用場景是部分通用,部分隔離的,這時候就需要引入“權限系統”了。

 

設計師有時會對角色權限系統有一絲畏難情緒。一方面因為角色權限系統的配置作為一個非常后臺的管理功能,在競品調研過程中很難通過上帝視角去解剖其中邏輯,自己琢磨又較難透徹;另一方面對于角色權限系統,做好了并不能代表設計能力有多優秀,但一旦沒做好就會導致整個流程不通、產品崩潰。所以設計師常對權限系統望而卻步。

以下就筆者的幾次權限設計經歷,提供一些所謂的經驗套路,希望各位設計師從此微笑迎接權限需求。

 

二、基于技術模型進行設計-RBAC模型

進行設計前,最好能夠理解技術模型。在業界接受度較高的功能權限模型是RBAC(Role-Based Access Control)模型,其基本理念是將“角色”這個概念賦予用戶,在系統中用戶與權限之間通過角色進行關聯,以這樣的方法來實現靈活配置。以下就模型與設計相關的幾點做一下簡單介紹。

 

1. 基本的RBAC模型

如果沒有角色的概念,系統中每加入一個用戶,就需要為這個用戶配置一遍權限,下圖是wiki中直接為用戶權限管理方式,可以看出管理成本巨大。

 

而引入“角色”概念后,如下圖即是RBAC模型中最基本的模型:用戶與角色可為多對一或多對多的關系,當一個用戶的角色為多對多時,當前用戶的權限是多個角色的并集。

 

此時只需要為角色賦予權限,能夠大大減輕管理負擔,同時將用戶與權限解耦,提供更大的靈活性。

 

2. 引入用戶組概念的RBAC模型

在大型平臺的應用上,試想如果用戶量上萬,新增一個角色時,可能需要為大量用戶都分配一遍新的角色,工程量仍然巨大,此時即可以引入用戶組的概念:如果部分用戶的使用場景是相對一致和基礎的,我們可以把這些用戶打包成一個組,基于這個組的對象進行角色和權限的賦予。

同理如果權限較多時也會存在一樣的問題,處理方式是引入權限組的概念,將使用場景相對固定的一組功能或權限打包成組賦予角色。但是一般來講一個系統中權限功能的體量是相對有限和可控的,所以實際應用中對權限組的使用較少。

 

下圖所示為mac系統中運行添加用戶組,并以用戶組為單位配置權限;

需要注意的是即使有用戶組或權限組的存在,也可以允許用戶或權限與角色直接關聯,這個可以視具體業務情況而定。

 

3. 角色繼承的RBAC模型

在一個業務場景中,如果角色需區分:設計主管、設計組長、設計成員,并且管理方式為向下兼容時,則需使用角色繼承的RBAC模型:上層角色繼承下層角色的全部權限,且可額外賦予權限。

此時除了對角色進行定義,還需要管理角色間的關系,通過關系來體現角色的層級關系,從而達到繼承權限的效果。角色的繼承關系主要有兩種:樹形圖和有向無環圖:

繼承關系常常來源于公司團隊的組織結構,此時常將角色與組織結構進行關聯達到繼承角色模型的效果;如下圖所示的趙同學,其角色是“三級團隊負責人”,與其并列的小組中有多個“三級團隊負責人”的角色,但依附于左側的組織結構樹,各級負責人僅有查看和操作自己下屬子節點的權限。

4. 限制的RBAC模型

在一個產品或系統中,部分角色可能是需要隔離的、不允許被同時賦予一個人的。跟大家熟知的“不能既是‘運動員’又是‘裁判員’ ”一個道理。

因此,對于眾多角色中的一組,只能是單選的關系,但多組角色之間可以共同存在。如下圖中,一個用戶可以既為設計師又為管理員,但在設計師角色組中僅能被賦予一個角色,在管理員角色組中也僅能被賦予一個角色。

此外,限制還有可能是數量上的,比如一個產品組中必須有且只有一個管理員,不允許刪除或再分配管理員角色,僅允許將負責人角色變更。

限制的模型不僅僅對分配過程產生影響,有時即使擁有了多種角色,因為不同的角色對同一個功能的使用方式或數據會產生沖突,所以使用時也需要進行限制。如下圖所示為同一時間僅允許以一個身份登錄。

根據不同的業務需求,限制的形式很多。需要注意的是不能僅依賴后端限制,而是要在前端展示清晰的規則和恰當的限制,避免用戶出錯和沮喪。

 

三、權限的拆分與設計

通過RBAC模型已經能夠很好的搭建起用戶、角色與權限之間的關系了。但具體是什么樣的關系,以及“權限”這個抽象的概念具體如何規劃?這些都需要分析清楚才能進一步設計出完善的權限系統。

首先需要知道,一般產品的權限由頁面、操作和數據構成。頁面與操作相互關聯,必須擁有頁面權限,才能分配該頁面下對應的操作權限。數據可被增刪改查。整體關系如下圖所示:

因此,在設計之初我們就需要考慮到未來可能區分角色的地方,盡量解耦、模塊化。對于技術來說,每一個頁面模塊、每一個操作都最好使用獨立的接口。對于設計來說,需要保障所有角色因為權限而屏蔽掉部分操作和數據后,頁面和流程仍能體驗流暢。

 

保證初期設計支持后,配置權限時,還需要注意以下幾點:

1. 確定是否支持前端配置

如果角色和權限相對固定,則一般將角色與權限的關系可以寫在后臺,改動時需要后端變更且重新上線;這種情況適用于公司內部系統等只有一個使用主體的系統。

如果需要自定義角色、或者每個角色在不同使用者的場景下有不同的權限,則需要將角色的定義、角色與權限之間的配置體現在“前端用戶配置頁面”;這種情況適用于有頻繁變動的自定義角色權限,和有租戶體系的系統。

 

2. 以基本單元拆分,以業務邏輯配置

一般可將每個對象的“增、刪、改、查”各自作為一個基本的權限單元。打個比方,在“人員管理”中,查看人員列表、添加人員、刪除人員、編輯人員信息最好拆分為4個權限單元。在技術和設計上,我們希望能盡量做到解耦和模塊化。

但是在業務層面有些操作卻是一體的。這些不能拆開的權限在“前端用戶配置頁面”中建議打包成一個整體提供配置。例如,如果我們確定在系統的現有和未來業務中,僅分為普通成員有“人員管理”的查看權限,管理員有操作權限,則可將“增、刪、改”三個基本權限單位合并為“操作”權限進行配置。

 

3. 頁面權限優先于操作和數據權限

必須配置了頁面模塊權限后,才能配置當前頁面模塊下具體的操作權限,以及頁面模塊的數據展示權限;

 

4. 查看權限優先于增刪改權限

正常情況下,一定要先能查看某個模塊或操作,其它的增刪改操作才有意義。因此在設計時,應在獲取查看權限前限制其它權限的配置;或者配置其它權限時默認賦予查看權限。

 

5. 角色與權限的多種關系

角色與權限的關系不僅是單純“是/否關系”,還包括以某種限制進行操作,和以某種程度訪問數據。例如在“人員管理”中:

  • 數據范圍:用戶擁有查看人員列表的權限,但僅能查看自己所在的團隊;
  • 數據邊界限制(上限等):添加人員時不能超過20個等。
  • 數據字段:HR能查看人員列表中包括職級、薪資等字段;其它角色僅能查看姓名郵箱等字段;

 

6. 角色與權限的設計表達

在傳達一個系統的權限設計規則時,設計師常常習慣用主觀最直接的方式表達想法,如用“當……時,就……”的句式來表達。但一個平臺中涉及的權限規則是非常多的,當通篇以這樣的形式描述時,表達對象將很難理解。

正確的描述方式:更清晰的是基于開發的語言,和技術模型的結果進行表達:將各角色與權限單元繪制成網格,每個交叉點網格中描述該角色與權限的數據關系和限制。如下圖所示:

 

四、需要注意的Tips

 

1. 隱形的admin

在可自定義角色和權限的系統中,一般需要預留一個admin角色來進行系統的初始配置,用于添加首批的業務人員和配置基本的角色。

有的系統中允許存在上帝視角的admin角色,則其可以作為“超級管理員”顯示在角色配置的列表中;有的系統中不允許這種角色存在,則可將這種角色設置為隱形的狀態,僅賦予維護系統的工作人員。

 

2. 初始權限的賦予

對于允許用戶自行加入的系統,需要設定一至多個默認的角色,有時可以是僅有最基礎權限的“游客”角色。

初始權限還可以與用戶既有的某些數據字段進行關聯。如添加用戶時獲取到用戶的崗位為“設計師”,則直接賦予“設計師”角色的權限。

 

3. 人員管理中對自己的處理

在人員管理中,管理員角色處理自己時需要額外注意:因為如果修改或刪除了自己角色后,可能導致系統沒有管理角色,從而無法添加其他成員和正常運行。設計時可添加判斷,當自己為唯一管理角色時,禁止編輯和刪除。

 

4. 無頁面權限的提示

雖然可以通過頁面權限限制直接隱藏當前用戶沒有權限的頁面,但不能排除用戶獲取到權限外的url地址。當用戶意外訪問到沒有權限的頁面時務必提供“無權限”的提示,避免用戶認為系統bug。

 

最后

總結一下,整個權限系統設計就是定義各個節點和節點間關系的過程。

節點包括:

  • 用戶
  • 用戶組
  • 角色
  • 角色組
  • 權限(頁面、操作、數據)
  • 權限組(頁面、操作、數據)

 

關系包括:

  • 是/否關系
  • 繼承關系
  • 限制關系(互斥、范圍限制、邊界限制、字段限制……)
  • ……

梳理清楚所有邏輯后,通過靈活定義節點和組合各節點之間的關,便能夠輕松完成角色權限設計的100種解法。

 

原文地址:網易UEDC(公眾號)

作者:蔣蕊遙

 

轉載請注明:學UI網 » 角色權限設計的100種解法

登錄收藏
 
你可能喜歡的:
情感化設計情感化設計
設計沉思錄 | 到家精選服務設計實戰經驗設計沉思錄 | 到家精選服務設計實戰經驗
logo設計全過程,從溝通到提案實用方法logo設計全過程,從溝通到提案實用方法
哇,這個作品好棒,具體哪好,我就說不出來了哇,這個作品好棒,具體哪好,我就說不出來了
如何打造海報級banner如何打造海報級banner
什么樣的設計技巧是我會的,而你不會?什么樣的設計技巧是我會的,而你不會?
作品不夠吸引眼球,應該如何解決作品不夠吸引眼球,應該如何解決
如何巧用氣泡,讓設計變得更高級如何巧用氣泡,讓設計變得更高級
組件化思維-提高設計效率等組件化思維-提高設計效率等
親測有效!這7個改版方向能快速讓人記住你的設計!親測有效!這7個改版方向能快速讓人記住你的設計!
?
网球比分雷速 大发快三彩票手机版 浙江11选5有什么问题 pk10最稳的看走 股票怎么开户支付宝 3d试机号100期 河南11选5走势图 481走势图泳坛夺金开奖结果 河北快三玩法中奖规则 江西快3预测准的方案 基金配资