前言

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

1.什么是「權限設計」

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

1.1.權限的意義

• 讓使用者在有效的限制范圍內訪問被授權的資源。

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

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

1.2.權限的應用

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

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

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

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

1.3.權限設計要求

好的權限設計，需要達到以下三方面要求：

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

• 關系明確：需要界定權限的邊界與關系，遵循一定的規則與用戶進行關聯。

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

1.4.權限設計的工作范疇

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

• 業務梳理：權限構成、賦予以及行使的邏輯、元素的梳理。

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

• 底層架構開發：偏向于開發層面的系統底層架構設計與研發。

權限系統的復雜度決定設計需要介入的層級深度；一般設計師在權限設計中的范疇包括厘清權限的業務邏輯、關注頁面本身的設計，其他的數據層面和實現層面即可交由產品和開發。

2.怎么做「權限設計」—業務梳理

2.1.準備工作：權限模型的了解與選擇

在業界有很多關于權限系統的技術模型，常見的有ACL、ABAC、DAC、RBAC等等，不同體量的權限系統，我們可以參考不同的權限模型進行梳理和設計。

2.1.1.RBAC0模型

RBAC0的基礎理念是將“角色”這個概念賦予用戶，在用戶與權限之間通過角色進行關聯，實現靈活配置。

RBAC模型的三要素為：用戶、角色、權限。

• 用戶：是發起操作的主體，例如：后臺管理系統的用戶、OA系統的內部員工、面向C端的用戶。

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

• 權限：用戶可以訪問的資源，包括：頁面權限、操作權限、數據權限。???

* 2.1.2.ACL模型

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

ACL權限中，只有用戶、權限這兩個要素：

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

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

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

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

• 互斥關系角色: 同一用戶只能分配到一組互斥角色集合中至多一個角色，互斥角色是指各自權限互相制約的兩個角色。例如：設計部有交互設計師和視覺設計師兩個角色，他們如果在系統中為互斥角色，那么用戶不能同時擁有這兩個角色，體現了職責分離原則。

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

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

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

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

2.2.1.第一步：盤點角色

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

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

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

🌰舉例，研發運維工具中的角色定義，不同的崗位對應不同的角色擁有不同工具的使用權。

• 根據任務流盤點：根據系統任務流對角色進行窮舉，即盤點需要創建哪些角色進行任務閉關。

🌰舉例，支撐A平臺的智能客服知識庫，角色是我們在產品規劃過程中為其定義產生的。

本步驟產出物：「角色列表」

2.2.2.第二步：盤點權限

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

頁面權限

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

🌰舉例，智能客服知識庫系統的頁面權限：

操作權限

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

🌰舉例，智能客服知識庫系統-敏感詞管理-黑名單頁面的操作權限：新增黑名單、修改、刪除

在實際操作場景中，部分操作權限會因狀態而發生變化，在盤點操作權限時，需要使用狀態流轉化圖來檢查是否有缺漏。

數據權限

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

根據用戶組是否有上下級的關系，可將用戶組分為：具上下級關系用戶組、普通用戶組。

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

🌰舉例：

針對事項的受理審批有較為嚴謹的流程，各個單位需要各司其職，且公眾辦理的事項隸屬于各級層級區域，所以平臺權限系統需要形成較為嚴謹的區域結構和部門組織。例如，市公安局、民政局、水利局的辦事數據是對立的，我們可通過部門組織建立的用戶組來隔離數據權限。

• 普通用戶組: 沒有上下級關系的用戶分組。在日常系統最常見的普通用戶組為“項目組”，按項目組來劃分用戶的數據權限。

🌰舉例，以應用項目的緯度控制用戶可訪問的數據范圍。

本步驟產出物：「權限點列表」

2.2.3.第三步：連接角色權限

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

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

🌰舉例：

本步驟產出物：「角色權限總表」

2.2.4.第四步：設計用戶導入與授權流程

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

明確賬號體系

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

初始用戶授權流程

• 已有賬號：如為公司域下中后臺的用戶導入，用戶賬號為現成的我們不需要考慮用戶的賬號。可直接為用戶賦予權限，授權分為兩種方式：為用戶選擇角色、為角色添加用戶。

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

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

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

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

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

授權申請流程

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

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

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

繪制狀態轉換圖

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

導入/授權后的消息通知

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

3.怎么做「權限設計」—界面設計

3.1.頁面權限設計點

無權限頁面申請指引設計

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

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

🌰舉例：無權限頁面?

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

🌰舉例：無權限頁面

3.2.數據權限設計點

數據權限范圍的展示與切換

在2.2.2章節中，數據權限的不同導致用戶在同一頁面看到的數據是不同的，數據權限的范圍可由具有層級關系的組織架構劃分，也可由普通用戶組進行劃分。通常，系統允許用戶擁有單個或多個數據權限；所以在我們的系統界面中，需要有承載數據權限范圍展示和切換的設計。

由于數據權限的展示和切換控制著用戶對于整個系統的數據范圍，故需要存在于系統架構的第一層級，一般可獨立放置于一級菜單之上。

🌰 舉例：項目切換

3.3.操作權限設計點

無權限操作展示設計

• 可申請

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

• 不可申請

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

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

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

總結

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

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

↘好文推薦：

干貨?|?產品經理要了解的技術類知識
復盤?|?產品經理晉級連勝的訣竅
如何正確解碼用戶的“玄學需求”？

👇歡迎關注：

點個“在看”吧

總結

以上是生活随笔為你收集整理的系统解读：权限设计指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。