干貨總結：B端業務系統用戶權限交互可用性設計

編輯導讀：B端業務系統中的用戶權限功能，是一個涉及到多個角色的復雜功能。如何在復雜邏輯下提升交互體驗呢？本文主要從用戶體驗的視角，通過具體的用戶權限交互設計案例分析，分享如何在復雜權限邏輯下提升用戶權限的交互體驗，理解用戶權限的通用設計原理-RBAC模型。

一、B端業務系統的功能共性

所有的B端業務系統都具有一條相同的功能共性——用戶權限功能，涉及多個角色。

比如，供應商管理系統、定價系統、CRM等涉及流程審批，Teambiton、石墨文檔、藍湖等項目協同工具也存在權限功能等等。

為什么B端業務系統都需要用戶權限功能？

根據筆者個人的理解，可以根據產品功能倒推其解決的問題是什么，以明晰需求真偽和需求價值。一般使用場景故事法去驗證功能需求，常用公式是某功能解決什么用戶在什么場景下具體什么問題。所以，用戶權限功能作為產品的解決方案，我們可以從B端產品服務的用戶群體和用戶需求場景進行思考。B端產品主要是面向企業組織服務，企業組織結構復雜，員工的職權范圍不同。

場景一：一個項目團隊在工作過程中，項目經理、產品經理、視覺設計師、前端開發和后端開發是不可以隨意修改交互設計師的設計稿的，否則設計不可控，出現矛盾和糾紛。

場景二：公司產品定價策略是不宜對外公開的，一旦泄密則需要追究責任，從公司信息安全角度，就需要限制員工職權。

因此，用戶權限功能解決的是企業或組織中員工的職權問題。

二、如何在復雜權限邏輯下提升交互體驗？

根據權限業務邏輯的復雜程度，可以有不同的權限設計策略。小到Figma這樣協作的設計工具，給每個項目成員設置具體項目編輯和查看權限，大到復雜的業務系統，涉及到復雜的權限邏輯，對某個頁面、模塊的功能操作權限和數據權限等。

圖：Figma 項目成員權限設置

不同的業務，其權限邏輯是不同的，但權限設計原理和交互體驗設計卻是相通的。下面通過兩個設計案例，分析用戶權限交互體驗設計思路和技巧。

2.1 案例一：藍湖項目權限交互設計

下圖是藍湖的項目成員權限設置界面。設計目的主要是幫助用戶高效設置項目團隊成員具體的權限。權限功能設計是基于角色的訪問控制RBAC模型，即圍繞用戶、角色和權限三者展開設計。用戶是指該項目中具體的成員，角色是指超級管理員、管理員、編輯者、查看者，權限則是指具體的項目權限項，如創建、刪除項目、編輯畫布、刪除團隊成員、移交團隊。不同的角色，其權限范圍不同。

同用戶和權限直接關聯的功能設計方案相比，通過引入角色，超級管理員無需給用戶單獨設置具體的權限項，一鍵完成，可有效提高權限設置效率。

圖：藍湖項目團隊權限設置

圍繞給用戶設置權限的目的，可拆分任務為創建權限、分配權限和使用權限。藍湖將創建權限和角色的權限項這一復雜邏輯轉移至系統，由系統設定好超級管理員、管理員、編輯者和查看者四種角色，并賦予每個角色對應的權限項，用戶只需要針對具體用戶設置角色即可，進一步提升了給用戶設置權限的效率，讓用戶權限設置變得更加簡單易用。

此外，邀請用戶加入項目，默認首選項是查看者角色。為什么？因為大多數場景下，用戶邀請的項目新成員只需要查看，所以默認首選項可以設置為查看者角色，提高了用戶邀請新成員加入項目的權限設置效率，如需變更權限，則點擊變更角色即可。

小結：

• 將復雜的權限邏輯轉移給系統解決，讓用戶設置權限更簡單。
• 從用戶主要場景出發，提供權限默認首選項。
• 基于角色訪問控制RBAC模型（Role-Based Access Control）進行權限功能設計，引入角色，提高分配權限效率。

2.2 案例二：T-PaaS平臺用戶權限交互體驗優化

下面以筆者負責的T-PaaS平臺用戶權限交互優化為例，闡述如何在復雜的權限邏輯下提升交互體驗。

首先，需求來源于用戶反饋，具體需求是用戶在新建權限時，交互效率低下，可用性差。

下圖是最終確定的交互設計方案，下面具體解釋一下為什么這樣設計，以及是如何想到這樣的設計方案，這樣的設計給用戶帶來的價值是什么，以此提煉出可提升權限交互體驗的一些思路和方法。

圖：T-PaaS平臺新建權限交互優化

整體設計過程分三個階段，分別是定義問題、解決問題和輸出交互原型設計方案。

階段一：問題診斷

分析用戶痛點，明確具體要解決什么問題。你是怎么知道體驗不好的？為什么不好呢？所以要先發現并驗證用戶需求痛點。可以通過分析用戶心智模型，同線上的設計模型對比匹配，找到并驗證用戶具體的使用痛點，而不是根據設計師自身的經驗去分析用戶痛點。

圖：模型匹配

用戶心智模型分析：

通過與產品經理詳細溝通得知，用戶權限功能的使用者是系統管理員，只有系統管理員才可見用戶權限功能模塊，所以鎖定目標用戶是管理員。用戶需求場景是：管理員給系統用戶設置權限時，通常是分配多個服務的權限，而每個服務又包含多個資源權限。

場景描述：管理員給某用戶設置多個不同實例的相關權限，而實例分散在不同集群下不同的應用。因此，判斷管理員用戶目標是給系統用戶同時設置多個服務的權限，這是目標用戶的心智模型。

線上設計模型分析：

線上的權限設計是引入權限組，權限組關聯具體的服務權限項設置，但是權限組和具體的服務權限是分開創建的。具體交互路徑是：管理員新建權限時，每次只能選擇單個服務并設置對應權限，創建完成后保存。如需新權限，則重復新建權限并保存。最后是新建權限組，從已創建的權限列表中選擇已設置好權限的服務，如下圖所示。

圖：線上新建權限組的交互路徑（優化前）

在大多數場景下，完成一個權限組的交互至少要9個步驟，而且還需要反復來回切換跳轉頁面。而用戶目標是給系統用戶同時設置多個服務的權限。從用戶體驗角度看，設計目標是幫助用戶高效設置多個服務的權限。而線上的設計模型無法同時設置多個服務的權限，無法更高效地匹配用戶的心智模型，所以問題確定是新建權限的效率比較低。

綜上，我們發現用戶具體的使用痛點是：管理員在新建權限組前，每次只能創建一個服務的權限，頁面來回跳轉，交互路徑過長，導致管理員在新建權限組時花費太多時間，效率比較低，用戶體驗不友好。

因此，確定設計目標是提高管理員新建權限的效率。

階段二：解決問題

圍繞設計目標——提高新建權限的效率，根據用戶具體的使用痛點，交互路徑長等問題，我們可以縮短其交互路徑，合并單個服務權限的創建，讓管理員一次性設置所需服務的權限，交互步驟縮短至三步完成。所以，變更后的交互方案是用戶新建權限，批量選擇所需服務并設置對應權限，完成權限創建，步驟如下圖所示。

圖：新建權限的交互路徑（優化后）

依然圍繞設計目標，再繼續拆解管理員新建權限的任務。我們將管理員新建權限的任務過程細分為選擇服務前、選擇服務時和選擇服務后三個行為節點，構思交互方案。

選擇服務前，需明確設計目的是如何幫助用戶找服務。有哪些服務？用戶找服務的目標是否明確？服務名稱是否易識別？根據什么方式排序便于查找服務？用戶常設置哪些服務？大概從這幾方面思考設計策略，幫助用戶選擇所需服務。而具體該如何解決這個問題，則需要深入了解當前權限具體的業務邏輯和用戶找服務的需求。

權限業務邏輯如下：

• 層級關系是服務-集群-應用-實例，應用空間與服務是并列關系，集群、應用、實例存在多個的情況。
• 服務的功能權限：查詢、增加、刪除、編輯、查看。
• 服務項56項，有新的服務時會遞增。
• 字段有權限名稱、描述、服務項權限設置

所以，我們從以上權限邏輯關系和數量范圍，可以確定的是目前服務數量是有限的，根據信息優先順序，先展示權限名稱，再展示服務權限設置，服務的資源條件使用多選樹狀結構展示，既清晰表達資源層級關系，又易于實現，如下圖所示。

圖：具體服務的資源條件設置

而且，服務權限設置模塊的下方已無內容。綜上，權限設置采用列表平鋪的方式全部展示，一目了然，查找服務效率高一些。

而用戶找服務目標是明確的，由于服務名稱多為英文字符，也無法確定哪些是常用服務，所以考慮列表采用按照服務名稱首字母A-Z的有序方式排列，使用列表索引方式幫助管理員查找服務。因為用戶在找服務的場景下，主要是依賴服務名稱查找，找東西本身是有記憶成本的，因此，服務名稱的定義、列表的排序方式是需要我們設計師深入思考的機會點，不要讓用戶思考。

當用戶選擇服務時，只需勾選即可。但是需要考慮點擊區域和服務名稱如何展示。選擇服務后，則需要考慮用戶具體要設置服務的哪些權限，如何設置具體的權限？可以根據大多數的場景提供默認功能權限的首選項，減少操作，提高效率。

此外，T-PaaS權限設計也使用了RBAC模型，平臺用戶對應的就是模型中的用戶，權限組（權限集合）對應的是角色，服務項對應的是模型中的具體權限。

小結：

• 針對交互流程繁瑣，回到目標用戶的需求場景，縮短交互步驟，合并重復流程，控制在三步內完成用戶任務。
• 權限服務項數量有限的情況下，權限服務項設置采用列表平鋪展示，一目了然，找服務效率更高。
• 通過用戶場景故事找到用戶目標，從而找到設計目標。
• 可通過對比設計模型和用戶心智模型是否匹配，挖掘并驗證用戶痛點。
• 圍繞用戶需求場景(問題)，不斷拆解設計目標到具體的任務行為節點，思考交互設計機會點，以解決問題。
• 權限體驗設計需要深入理解具體業務的權限邏輯和用戶需求場景。
• 給用戶設置權限需要考慮去重處理，如果有重復，取并集。
• 權限是集合關系。
• 基于角色的訪問控制（RBAC）模型設計權限。

以上即為新建權限交互優化的思考過程和交互體驗可思考的設計機會點，僅拋磚引玉。

三、用戶權限設計原理RBAC模型

以上兩個權限設計案例，都使用了RBAC（Role-Based Access Control）模型，也是目前B端業務系統權限功能設計普遍使用的設計模型。

RBAC模型指的是基于角色的訪問控制。具體而言，就是用戶通過角色與權限進行關聯。通過引入角色，提高用戶分配權限效率。RBAC模型由用戶、角色和權限組成。一般而言，用戶和角色是多對一關系，角色和權限是一對多的關系，如下圖所示。

圖：RBAC模型及對應關系示意

用戶是指參與系統活動的主體 。角色指的是特定權限的集合，如藍湖權限角色超級管理員、編輯者和查看者，每個角色是被賦予了權限的集合體。而權限則是角色對頁面、模塊的具體功能操作和數據權限等，是具體的權限項，如編輯者可編輯畫布、管理設計圖、批注。

權限具體會包含頁面權限、功能操作權限和數據權限。頁面權限是指只有特定用戶才有權限訪問的頁面，例如財務可以查看公司的財務報表，而運維人員不可以。功能操作權限，就是用戶對頁面或模塊具有的增刪改查等權限，比如藍湖項目文檔，只有項目超級管理員、管理員可以修改文檔，研發是不可以修改的。而數據權限，就是用戶可查看哪些數據。比如集團企業老板可以看到集團下各分公司的全部銷售數據，而分公司的總經理只能看到自己所在分公司的銷售數據，其他分公司的銷售數據是看不到的。

此外，為了解決更復雜的權限業務邏輯，RBAC模型也在不斷升級。比如，在角色中引入繼承關系，把角色分成幾個等級，每個等級權限不同，實現更細顆粒度的權限管理。或者，增加用戶組，管理員直接給用戶組分配角色，再把用戶加入到用戶組，可以批量給更多用戶賦予同一角色的權限，用戶除了擁有自身的權限外，還擁有所屬用戶組的所有權限。

四、總結

本文主要圍繞B端業務系統的功能共性-用戶權限，通過兩個權限設計案例，介紹了如何在復雜權限邏輯下提升交互體驗的方法。具體總結了12點設計心得，幫助大家在做用戶權限體驗設計時，有一些幫助和啟發。

• 將復雜的權限邏輯轉移給系統解決，讓用戶設置權限更簡單。
• 從用戶主要場景出發，提供權限默認首選項。
• 針對交互流程繁瑣，回到目標用戶的需求場景，縮短交互步驟，合并重復流程，控制在三步內完成用戶任務。
• 權限項數量有限的情況下，權限項設置采用列表平鋪展示，一目了然，找服務效率更高。
• 通過用戶場景故事找到設計目標。
• 可通過對比設計模型和用戶心智模型是否匹配，挖掘并驗證用戶痛點。
• 圍繞用戶需求場景(問題)，不斷拆解設計目標到具體的任務行為節點，思考交互設計機會點，以解決問題。
• 權限體驗設計需要深入理解具體業務的權限邏輯和用戶需求場景。
• 給用戶設置權限需要考慮去重處理，如果有重復，取并集。
• 權限是集合關系。
• 權限顆粒度盡可能更小。
• 基于角色訪問控制RBAC模型（Role-Based Access Control）進行權限功能設計，引入角色，結合具體業務，把角色分成等級或引入用戶組，提高目標用戶分配權限效率。

 

本文由 @沉一 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議