編輯導讀：B端業務系統中的用户權限功能，是一個涉及到多個角色的複雜功能。如何在複雜邏輯下提升交互體驗呢？本文主要從用户體驗的視角，通過具體的用户權限交互設計案例分析，分享如何在複雜權限邏輯下提升用户權限的交互體驗，理解用户權限的通用設計原理-RBAC模型。
所有的B端業務系統都具有一條相同的功能共性——用户權限功能，涉及多個角色。
比如，供應商管理系統、定價系統、CRM等涉及流程審批，Teambiton、石墨文檔、藍湖等項目協同工具也存在權限功能等等。
為什麼B端業務系統都需要用户權限功能？
根據筆者個人的理解，可以根據產品功能倒推其解決的問題是什麼，以明晰需求真偽和需求價值。一般使用場景故事法去驗證功能需求，常用公式是某功能解決什麼用户在什麼場景下具體什麼問題。所以，用户權限功能作為產品的解決方案，我們可以從B端產品服務的用户羣體和用户需求場景進行思考。B端產品主要是面向企業組織服務，企業組織結構複雜，員工的職權範圍不同。
場景一：一個項目團隊在工作過程中，項目經理、產品經理、視覺設計師、前端開發和後端開發是不可以隨意修改交互設計師的設計稿的，否則設計不可控，出現矛盾和糾紛。
場景二：公司產品定價策略是不宜對外公開的，一旦泄密則需要追究責任，從公司信息安全角度，就需要限制員工職權。
因此，用户權限功能解決的是企業或組織中員工的職權問題。
二、如何在複雜權限邏輯下提升交互體驗？根據權限業務邏輯的複雜程度，可以有不同的權限設計策略。小到Figma這樣協作的設計工具，給每個項目成員設置具體項目編輯和查看權限，大到複雜的業務系統，涉及到複雜的權限邏輯，對某個頁面、模塊的功能操作權限和數據權限等。
圖：Figma 項目成員權限設置
不同的業務，其權限邏輯是不同的，但權限設計原理和交互體驗設計卻是相通的。下面通過兩個設計案例，分析用户權限交互體驗設計思路和技巧。
2.1 案例一：藍湖項目權限交互設計下圖是藍湖的項目成員權限設置界面。設計目的主要是幫助用户高效設置項目團隊成員具體的權限。權限功能設計是基於角色的訪問控制RBAC模型，即圍繞用户、角色和權限三者展開設計。用户是指該項目中具體的成員，角色是指超級管理員、管理員、編輯者、查看者，權限則是指具體的項目權限項，如創建、刪除項目、編輯畫布、刪除團隊成員、移交團隊。不同的角色，其權限範圍不同。
同用户和權限直接關聯的功能設計方案相比，通過引入角色，超級管理員無需給用户單獨設置具體的權限項，一鍵完成，可有效提高權限設置效率。
圖：藍湖項目團隊權限設置
圍繞給用户設置權限的目的，可拆分任務為創建權限、分配權限和使用權限。藍湖將創建權限和角色的權限項這一複雜邏輯轉移至系統，由系統設定好超級管理員、管理員、編輯者和查看者四種角色，並賦予每個角色對應的權限項，用户只需要針對具體用户設置角色即可，進一步提升了給用户設置權限的效率，讓用户權限設置變得更加簡單易用。
此外，邀請用户加入項目，默認首選項是查看者角色。為什麼？因為大多數場景下，用户邀請的項目新成員只需要查看，所以默認首選項可以設置為查看者角色，提高了用户邀請新成員加入項目的權限設置效率，如需變更權限，則點擊變更角色即可。
小結：
- 將複雜的權限邏輯轉移給系統解決，讓用户設置權限更簡單。
- 從用户主要場景出發，提供權限默認首選項。
- 基於角色訪問控制RBAC模型（Role-Based Access Control）進行權限功能設計，引入角色，提高分配權限效率。
下面以筆者負責的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 協議