本文針對初階的產(chǎn)品經(jīng)理、產(chǎn)品體驗設計師，以及承擔部分產(chǎn)品邊界工作的交互設計師，較為系統(tǒng)地介紹了中后臺權(quán)限系統(tǒng)的模型組成以及元素梳理、流程界面設計的諸多要點，讀者可以以此來自查梳理內(nèi)容是否充分以及獲取權(quán)限界面設計中的要點干貨。

1.什么是「權(quán)限設計」

“權(quán)限設計”是中后臺的底層設計，用于明確操作人員可在平臺內(nèi)能做什么；即什么樣的人，可以做什么樣的事。

1.1.權(quán)限的意義

• 讓使用者在有效的限制范圍內(nèi)訪問被授權(quán)的資源。

• 讓管理者基于系統(tǒng)的安全規(guī)則與策略，控制不同用戶合理訪問對應資源。

正是有了權(quán)限系統(tǒng)，才可以讓工作群組內(nèi)不同人員、不同組織的分工，讓不同角色專注于自己的工作范圍，也可以降低操作風險發(fā)生概率，也便于管理。

1.2.權(quán)限的應用

權(quán)限設計的應用主要有兩種場景，分別是版本切割、角色權(quán)限管理：

• 角色權(quán)限管理：角色權(quán)限管理顧名思義是根據(jù)用戶角色類型進行權(quán)限分配；一個角色對應一組權(quán)限組，一個用戶可能有多個角色。適用于中后臺邏輯復雜功能模塊繁多，需要對系統(tǒng)按權(quán)限進行切割的應用場景。

• 版本管理：部分中后臺存在商業(yè)化訴求，基于前者的角色權(quán)限分配（也有可能不存在角色區(qū)分），再將完整的系統(tǒng)進行功能切割，將整個系統(tǒng)按功能切割為普通版、進階版，甚至更多版本；這些版本功能范圍基本處于一個包含關(guān)系。

在B端中后臺的設計中，最常見的應用場景為“角色權(quán)限管理”，角色權(quán)限管理涉及的維度也會比“版本切割”更為復雜，本指南會著重介紹角色權(quán)限管理場景下的設計。

1.3.權(quán)限設計要求

好的權(quán)限設計，需要達到以下三方面要求：

• 系統(tǒng)安全：基于系統(tǒng)的安全規(guī)則和策略進行設計，同時需要降低用戶操作錯誤導致的風險概率。

• 關(guān)系明確：需要界定權(quán)限的邊界與關(guān)系，遵循一定的規(guī)則與用戶進行關(guān)聯(lián)。

• 拓展性高：需要確保權(quán)限管理的拓展性，系統(tǒng)的能力建設是持續(xù)的，用戶也是不斷流動的；保持高拓展性以此降低變更對安全性、穩(wěn)定性的影響。

1.4.權(quán)限設計的工作范疇

• 界面設計：權(quán)限查詢、管理與授權(quán)等一系列頁面設計。

• 業(yè)務梳理：權(quán)限構(gòu)成、賦予以及行使的邏輯、元素的梳理。

• 數(shù)據(jù)驗證&管理：數(shù)據(jù)管理層面，最終目標是可被表達成一個運算則式，體驗方案的合理性與拓展性，驗證設計的有效性。

• 底層架構(gòu)開發(fā)：偏向于開發(fā)層面的系統(tǒng)底層架構(gòu)設計與研發(fā)。

權(quán)限系統(tǒng)的復雜度決定設計需要介入的層級深度；一般設計師在權(quán)限設計中的范疇包括厘清權(quán)限的業(yè)務邏輯、關(guān)注頁面本身的設計，其他的數(shù)據(jù)層面和實現(xiàn)層面即可交由產(chǎn)品和開發(fā)。

2.怎么做「權(quán)限設計」—業(yè)務梳理

2.1.準備工作：權(quán)限模型的了解與選擇

在業(yè)界有很多關(guān)于權(quán)限系統(tǒng)的技術(shù)模型，常見的有ACL、ABAC、DAC、RBAC等等，不同體量的權(quán)限系統(tǒng)，我們可以參考不同的權(quán)限模型進行梳理和設計。

2.1.1.RBAC0模型

RBAC0的基礎理念是將“角色”這個概念賦予用戶，在用戶與權(quán)限之間通過角色進行關(guān)聯(lián)，實現(xiàn)靈活配置。

RBAC模型的三要素為：用戶、角色、權(quán)限。

• 用戶：是發(fā)起操作的主體，例如：后臺管理系統(tǒng)的用戶、OA系統(tǒng)的內(nèi)部員工、面向C端的用戶。

• 角色：用于連接了用戶和權(quán)限的橋梁，每個角色可以關(guān)聯(lián)多個權(quán)限，同時一個用戶也可以關(guān)聯(lián)多個角色，那么這個用戶就有了多個角色的多個權(quán)限。

• 權(quán)限：用戶可以訪問的資源，包括：頁面權(quán)限、操作權(quán)限、數(shù)據(jù)權(quán)限。

* 2.1.2.ACL模型

ACL為查詢操作對象的權(quán)限控制列表。當權(quán)限系統(tǒng)體量小，用戶直接對應具體功能點即可滿足系統(tǒng)訴求時，可以考慮使用ACL模型作為參考。

ACL權(quán)限中，只有用戶、權(quán)限這兩個要素：

* 2.1.3.RBAC1模型：基于 RBAC0 加入角色繼承

RBAC1模型是在RBAC0模型基礎上，引入了角色繼承的概念，即角色具有上下級的關(guān)系，每個等級權(quán)限不同，從而實現(xiàn)更細粒度的權(quán)限管理。

* 2.1.4.RBAC2 模型：基于 RBAC0 引入角色約束控制

RBAC2模型是在RBAC0模型基礎上，對角色進行約束控制。RBAC2模型中添加了責任分離關(guān)系，規(guī)定了權(quán)限被賦予角色時或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規(guī)則。主要包括以下約束:

• 互斥關(guān)系角色: 同一用戶只能分配到一組互斥角色集合中至多一個角色，互斥角色是指各自權(quán)限互相制約的兩個角色。例如：設計部有交互設計師和視覺設計師兩個角色，他們?nèi)绻谙到y(tǒng)中為互斥角色，那么用戶不能同時擁有這兩個角色，體現(xiàn)了職責分離原則。

• 基數(shù)約束: a.一個角色被分配的用戶數(shù)量受限；b.一個用戶可擁有的角色數(shù)目受限；c.同一個角色對應的訪問權(quán)限數(shù)目受限；以此控制高級權(quán)限在系統(tǒng)中的分配。

• 先決條件角色: 簡單理解即如果某用戶想獲得上級角色，必須得先獲得其下一級的角色，以此為一個先決條件。

2.2.開始梳理：基于RBAC模型盤點要素

RBAC0在實際工作中用得較為頻繁，且對應初階的設計師對于權(quán)限的理解也較為有幫助，所以本文接下來會基于RBAC模型來介紹權(quán)限系統(tǒng)的梳理及設計。

2.2.1.第一步：盤點角色

角色是連接用戶和權(quán)限的橋梁，在這一步對參與系統(tǒng)的角色進行窮舉，需要保證系統(tǒng)的運作能否絕對閉環(huán)，所以明確系統(tǒng)中的角色至關(guān)重要。

如何進行角色盤點，主要有以下兩種方式：

• 參考組織本身的崗位劃分：絕大多數(shù)情況下，系統(tǒng)中的工作職責與實際工作崗位有較為緊密的相關(guān)性，我們可以參考已有的崗位來盤點系統(tǒng)中的角色。

?舉例，研發(fā)運維工具中的角色定義，不同的崗位對應不同的角色擁有不同工具的使用權(quán)。

• 根據(jù)任務流盤點：根據(jù)系統(tǒng)任務流對角色進行窮舉，即盤點需要創(chuàng)建哪些角色進行任務閉關(guān)。

?舉例，支撐A平臺的智能客服知識庫，角色是我們在產(chǎn)品規(guī)劃過程中為其定義產(chǎn)生的。

本步驟產(chǎn)出物：「角色列表」

2.2.2.第二步：盤點權(quán)限

權(quán)限是用戶能夠訪問的資源，本步驟需要將系統(tǒng)中所有權(quán)限點按照類型進行整理歸類，最終成表。權(quán)限點主要有以下幾種類型需要盤點：

頁面權(quán)限

通俗講即用戶在系統(tǒng)內(nèi)可見的頁面，由導航/菜單來控制，包括一級導航/菜單、二級導航/菜單，甚至三級導航/菜單；只要用戶有對應導航/菜單的權(quán)限即可訪問頁面。

?舉例，智能客服知識庫系統(tǒng)的頁面權(quán)限：

操作權(quán)限

通俗講即頁面的功能按鈕，包括查看、新增、修改、刪除、審核等等。

?舉例，智能客服知識庫系統(tǒng)-敏感詞管理-黑名單頁面的操作權(quán)限：新增黑名單、修改、刪除

在實際操作場景中，部分操作權(quán)限會因狀態(tài)而發(fā)生變化，在盤點操作權(quán)限時，需要使用狀態(tài)流轉(zhuǎn)化圖來檢查是否有缺漏。

數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限就是用戶在同一頁面看到的數(shù)據(jù)是不同的，比如：A部門只能看到其部門下的數(shù)據(jù)，B部門只看B部門的數(shù)據(jù)。數(shù)據(jù)權(quán)限分割的解決方案為：創(chuàng)建用戶組——將相同屬性或相同數(shù)據(jù)范圍訴求的用戶進行編組，不同的用戶組則享有不同的數(shù)據(jù)權(quán)限。

根據(jù)用戶組是否有上下級的關(guān)系，可將用戶組分為：具上下級關(guān)系用戶組、普通用戶組。

• 具上下級關(guān)系用戶組:最典型的例子就是部門組織。

?舉例：

針對事項的受理審批有較為嚴謹?shù)牧鞒?，各個單位需要各司其職，且公眾辦理的事項隸屬于各級層級區(qū)域，所以平臺權(quán)限系統(tǒng)需要形成較為嚴謹?shù)膮^(qū)域結(jié)構(gòu)和部門組織。例如，市公安局、民政局、水利局的辦事數(shù)據(jù)是對立的，我們可通過部門組織建立的用戶組來隔離數(shù)據(jù)權(quán)限。

• 普通用戶組: 沒有上下級關(guān)系的用戶分組。在日常系統(tǒng)最常見的普通用戶組為“項目組”，按項目組來劃分用戶的數(shù)據(jù)權(quán)限。

?舉例，以應用項目的緯度控制用戶可訪問的數(shù)據(jù)范圍。

本步驟產(chǎn)出物：「權(quán)限點列表」

2.2.3.第三步：連接角色權(quán)限

本步驟主要工作在于連接權(quán)限點與角色的關(guān)系，最終整理出一張完整的角色權(quán)限表。在梳理角色和權(quán)限的關(guān)系時，可以借助設計分析方法“角色任務行為窮舉”來進行權(quán)限點轉(zhuǎn)化和連接。

通常情況下，用戶為達成目標而需完成某些任務，這些任務以及任務的聚合往往會影響我們對于整個系統(tǒng)信息架構(gòu)的設計考量。所以各個角色的任務經(jīng)常與我們的頁面一一對應，從而產(chǎn)生頁面權(quán)限。而又因為完成任務需要進行一些特定的行為，而這些行為又與操作按鈕一一對應，從而產(chǎn)生了操作權(quán)限。

?舉例：

本步驟產(chǎn)出物：「角色權(quán)限總表」

2.2.4.第四步：設計用戶導入與授權(quán)流程

在建立了角色與權(quán)限的關(guān)系后，需要去明確用戶授權(quán)/導入的方式，并給導入的用戶賦予角色權(quán)限。

明確賬號體系

有部分公司域下的中后臺，用戶已有有統(tǒng)一的驗證方式，例如：騰訊OA身份驗證；也有部分中后臺需要用戶創(chuàng)建獨立的ID賬號密碼作為身份驗證。我們首先需要去明確我們設計的中后臺是以上哪種方式作為身份驗證，這將影響用戶導入流程的設計。

初始用戶授權(quán)流程

• 已有賬號：如為公司域下中后臺的用戶導入，用戶賬號為現(xiàn)成的我們不需要考慮用戶的賬號?？芍苯訛橛脩糍x予權(quán)限，授權(quán)分為兩種方式：為用戶選擇角色、為角色添加用戶。

為用戶選擇角色可用在單個授權(quán)的場景，以下為授權(quán)流程可供參考：

為角色添加用戶可用在批量授權(quán)的場景，以下為授權(quán)流程可供參考：

為豐富場景，提升體驗，建議兩種方式共存。

• 無賬號：如需要用戶創(chuàng)建ID的用戶導入，則適用于以下流程：

為保障安全，邀請碼需具有時效性。

授權(quán)申請流程

在實際工作中，用戶為完成某項任務卻無權(quán)限時，需要為用戶提供清晰的申請流程。申請權(quán)限有兩種場景。

• 場景一：權(quán)限存在崗位身份之分，身份與某組權(quán)限進行綁定，用戶主動申請崗位身份并獲得審批通過后，即可獲得該組權(quán)限，流程參考下圖：

• 場景二：用戶在訪問系統(tǒng)時，系統(tǒng)頁面提示用戶無訪問/操作權(quán)限，用戶針對該頁面/操作進行權(quán)限申請，通過后即可獲得該頁面/操作權(quán)限，流程參考下圖：

繪制狀態(tài)轉(zhuǎn)換圖

如果需要展示狀態(tài)轉(zhuǎn)換關(guān)系，關(guān)注狀態(tài)變化過程，甚至是檢測流程是否存在缺陷，我們可以通過繪制狀態(tài)轉(zhuǎn)換圖來梳理流轉(zhuǎn)狀態(tài)。使用狀態(tài)圖的過程中，設計師可以清晰的了解同一界面的各種狀態(tài)，便于對設計方案系統(tǒng)化的進行設計。在同一界面中，可以模塊化對比設計差異內(nèi)容。

導入/授權(quán)后的消息通知

消息通知可以及時地將狀態(tài)、內(nèi)容的更新觸達到用戶。在權(quán)限系統(tǒng)中，導入用戶環(huán)節(jié)或者是審批用戶權(quán)限環(huán)節(jié)，都離不開及時的消息通知。特別是導入用戶環(huán)節(jié)，為了確保安全性，邀請碼具有一定的時效性，所以消息的及時傳遞非常重要，務必需要對用戶進行及時的消息推送。

3.怎么做「權(quán)限設計」—界面設計

3.1.頁面權(quán)限設計點

無權(quán)限頁面申請指引設計

在2.2.4章節(jié)中，我們提到用戶在實際工作中為完成某項任務，對無權(quán)限頁面/操作會存在申請的場景訴求，我們除了要為用戶提供清晰的申請流程，也需要有清晰的指引，實際上也是針對空狀態(tài)的設計。

• 線上申請：用戶通過觸發(fā)申請按鈕，發(fā)起申請，并在線上填寫表單完成申請。在此場景下，除了申請按鈕，我們需要也很明確的告知用戶當前為無權(quán)限的狀態(tài)，甚至將原因也給予簡單說明；同時建議告知用戶申請的審批人是誰，需要審批多久。

?舉例：無權(quán)限頁面

• 線下申請：頁面僅告訴用戶申請方式，一般為授權(quán)人的聯(lián)系方式。

?舉例：無權(quán)限頁面

3.2.數(shù)據(jù)權(quán)限設計點

數(shù)據(jù)權(quán)限范圍的展示與切換

在2.2.2章節(jié)中，數(shù)據(jù)權(quán)限的不同導致用戶在同一頁面看到的數(shù)據(jù)是不同的，數(shù)據(jù)權(quán)限的范圍可由具有層級關(guān)系的組織架構(gòu)劃分，也可由普通用戶組進行劃分。通常，系統(tǒng)允許用戶擁有單個或多個數(shù)據(jù)權(quán)限；所以在我們的系統(tǒng)界面中，需要有承載數(shù)據(jù)權(quán)限范圍展示和切換的設計。

由于數(shù)據(jù)權(quán)限的展示和切換控制著用戶對于整個系統(tǒng)的數(shù)據(jù)范圍，故需要存在于系統(tǒng)架構(gòu)的第一層級，一般可獨立放置于一級菜單之上。

? 舉例：項目切換

3.3.操作權(quán)限設計點

無權(quán)限操作展示設計

• 可申請

對于開放申請的操作權(quán)限的展示，可將操作權(quán)限點置灰，表示用戶當前不可操作；在用戶hover置灰權(quán)限點時，提供氣泡提示置灰原因為無操作權(quán)限并提供申請權(quán)限入口。

• 不可申請

有些系統(tǒng)要求用戶可見操作全貌，即所有操作無論是否有權(quán)限都為可見的；若無權(quán)限則且不可申請，則直接置灰操作

有些系統(tǒng)要求"可見即可操作"，即為有權(quán)限的操作則顯示，無權(quán)限的操作則隱藏，這里就需要前端來配合，前端開發(fā)把用戶的權(quán)限信息緩存，在頁面判斷用戶是否包含此權(quán)限。

站在用戶體驗角度，更建議用后者這種方式進行權(quán)限隔離。

總結(jié)

在中后臺中，權(quán)限系統(tǒng)或許不像業(yè)務模塊一樣備受重視，僅僅只是中后臺背后默默支撐的功能，但卻是必不可忽視的，正是有了權(quán)限系統(tǒng)，才可以讓工作群組內(nèi)不同人員、不同組織的分工，讓不同角色專注于自己的工作范圍，降低操作風險發(fā)生概率，便于管理。

在實際項目中，會遇到多個系統(tǒng)、多個用戶類型、多個使用場景，這需要具體問題具體分析；但萬變不離其宗，不管多么復雜，邏輯如何變化，最核心的RBAC模型還是一樣適用。