編輯導(dǎo)讀：B端業(yè)務(wù)系統(tǒng)中的用戶權(quán)限功能，是一個(gè)涉及到多個(gè)角色的復(fù)雜功能。如何在復(fù)雜邏輯下提升交互體驗(yàn)?zāi)?？本文主要從用戶體驗(yàn)的視角，通過具體的用戶權(quán)限交互設(shè)計(jì)案例分析，分享如何在復(fù)雜權(quán)限邏輯下提升用戶權(quán)限的交互體驗(yàn)，理解用戶權(quán)限的通用設(shè)計(jì)原理-RBAC模型。

一、B端業(yè)務(wù)系統(tǒng)的功能共性

所有的B端業(yè)務(wù)系統(tǒng)都具有一條相同的功能共性——用戶權(quán)限功能，涉及多個(gè)角色。

比如，供應(yīng)商管理系統(tǒng)、定價(jià)系統(tǒng)、CRM等涉及流程審批，Teambiton、石墨文檔、藍(lán)湖等項(xiàng)目協(xié)同工具也存在權(quán)限功能等等。

為什么B端業(yè)務(wù)系統(tǒng)都需要用戶權(quán)限功能？

根據(jù)筆者個(gè)人的理解，可以根據(jù)產(chǎn)品功能倒推其解決的問題是什么，以明晰需求真?zhèn)魏托枨髢r(jià)值。一般使用場景故事法去驗(yàn)證功能需求，常用公式是某功能解決什么用戶在什么場景下具體什么問題。所以，用戶權(quán)限功能作為產(chǎn)品的解決方案，我們可以從B端產(chǎn)品服務(wù)的用戶群體和用戶需求場景進(jìn)行思考。B端產(chǎn)品主要是面向企業(yè)組織服務(wù)，企業(yè)組織結(jié)構(gòu)復(fù)雜，員工的職權(quán)范圍不同。

場景一：一個(gè)項(xiàng)目團(tuán)隊(duì)在工作過程中，項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、視覺設(shè)計(jì)師、前端開發(fā)和后端開發(fā)是不可以隨意修改交互設(shè)計(jì)師的設(shè)計(jì)稿的，否則設(shè)計(jì)不可控，出現(xiàn)矛盾和糾紛。

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

因此，用戶權(quán)限功能解決的是企業(yè)或組織中員工的職權(quán)問題。

二、如何在復(fù)雜權(quán)限邏輯下提升交互體驗(yàn)？

根據(jù)權(quán)限業(yè)務(wù)邏輯的復(fù)雜程度，可以有不同的權(quán)限設(shè)計(jì)策略。小到Figma這樣協(xié)作的設(shè)計(jì)工具，給每個(gè)項(xiàng)目成員設(shè)置具體項(xiàng)目編輯和查看權(quán)限，大到復(fù)雜的業(yè)務(wù)系統(tǒng)，涉及到復(fù)雜的權(quán)限邏輯，對某個(gè)頁面、模塊的功能操作權(quán)限和數(shù)據(jù)權(quán)限等。

圖：Figma 項(xiàng)目成員權(quán)限設(shè)置

不同的業(yè)務(wù)，其權(quán)限邏輯是不同的，但權(quán)限設(shè)計(jì)原理和交互體驗(yàn)設(shè)計(jì)卻是相通的。下面通過兩個(gè)設(shè)計(jì)案例，分析用戶權(quán)限交互體驗(yàn)設(shè)計(jì)思路和技巧。

2.1 案例一：藍(lán)湖項(xiàng)目權(quán)限交互設(shè)計(jì)

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

同用戶和權(quán)限直接關(guān)聯(lián)的功能設(shè)計(jì)方案相比，通過引入角色，超級管理員無需給用戶單獨(dú)設(shè)置具體的權(quán)限項(xiàng)，一鍵完成，可有效提高權(quán)限設(shè)置效率。

圖：藍(lán)湖項(xiàng)目團(tuán)隊(duì)權(quán)限設(shè)置

圍繞給用戶設(shè)置權(quán)限的目的，可拆分任務(wù)為創(chuàng)建權(quán)限、分配權(quán)限和使用權(quán)限。藍(lán)湖將創(chuàng)建權(quán)限和角色的權(quán)限項(xiàng)這一復(fù)雜邏輯轉(zhuǎn)移至系統(tǒng)，由系統(tǒng)設(shè)定好超級管理員、管理員、編輯者和查看者四種角色，并賦予每個(gè)角色對應(yīng)的權(quán)限項(xiàng)，用戶只需要針對具體用戶設(shè)置角色即可，進(jìn)一步提升了給用戶設(shè)置權(quán)限的效率，讓用戶權(quán)限設(shè)置變得更加簡單易用。

此外，邀請用戶加入項(xiàng)目，默認(rèn)首選項(xiàng)是查看者角色。為什么？因?yàn)榇蠖鄶?shù)場景下，用戶邀請的項(xiàng)目新成員只需要查看，所以默認(rèn)首選項(xiàng)可以設(shè)置為查看者角色，提高了用戶邀請新成員加入項(xiàng)目的權(quán)限設(shè)置效率，如需變更權(quán)限，則點(diǎn)擊變更角色即可。

小結(jié)：

• 將復(fù)雜的權(quán)限邏輯轉(zhuǎn)移給系統(tǒng)解決，讓用戶設(shè)置權(quán)限更簡單。
• 從用戶主要場景出發(fā)，提供權(quán)限默認(rèn)首選項(xiàng)。
• 基于角色訪問控制RBAC模型（Role-Based Access Control）進(jìn)行權(quán)限功能設(shè)計(jì)，引入角色，提高分配權(quán)限效率。

2.2 案例二：T-PaaS平臺用戶權(quán)限交互體驗(yàn)優(yōu)化

下面以筆者負(fù)責(zé)的T-PaaS平臺用戶權(quán)限交互優(yōu)化為例，闡述如何在復(fù)雜的權(quán)限邏輯下提升交互體驗(yàn)。

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

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

圖：T-PaaS平臺新建權(quán)限交互優(yōu)化

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

階段一：問題診斷

分析用戶痛點(diǎn)，明確具體要解決什么問題。你是怎么知道體驗(yàn)不好的？為什么不好呢？所以要先發(fā)現(xiàn)并驗(yàn)證用戶需求痛點(diǎn)?？梢酝ㄟ^分析用戶心智模型，同線上的設(shè)計(jì)模型對比匹配，找到并驗(yàn)證用戶具體的使用痛點(diǎn)，而不是根據(jù)設(shè)計(jì)師自身的經(jīng)驗(yàn)去分析用戶痛點(diǎn)。

圖：模型匹配

用戶心智模型分析：

通過與產(chǎn)品經(jīng)理詳細(xì)溝通得知，用戶權(quán)限功能的使用者是系統(tǒng)管理員，只有系統(tǒng)管理員才可見用戶權(quán)限功能模塊，所以鎖定目標(biāo)用戶是管理員。用戶需求場景是：管理員給系統(tǒng)用戶設(shè)置權(quán)限時(shí)，通常是分配多個(gè)服務(wù)的權(quán)限，而每個(gè)服務(wù)又包含多個(gè)資源權(quán)限。

場景描述：管理員給某用戶設(shè)置多個(gè)不同實(shí)例的相關(guān)權(quán)限，而實(shí)例分散在不同集群下不同的應(yīng)用。因此，判斷管理員用戶目標(biāo)是給系統(tǒng)用戶同時(shí)設(shè)置多個(gè)服務(wù)的權(quán)限，這是目標(biāo)用戶的心智模型。

線上設(shè)計(jì)模型分析：

線上的權(quán)限設(shè)計(jì)是引入權(quán)限組，權(quán)限組關(guān)聯(lián)具體的服務(wù)權(quán)限項(xiàng)設(shè)置，但是權(quán)限組和具體的服務(wù)權(quán)限是分開創(chuàng)建的。具體交互路徑是：管理員新建權(quán)限時(shí)，每次只能選擇單個(gè)服務(wù)并設(shè)置對應(yīng)權(quán)限，創(chuàng)建完成后保存。如需新權(quán)限，則重復(fù)新建權(quán)限并保存。最后是新建權(quán)限組，從已創(chuàng)建的權(quán)限列表中選擇已設(shè)置好權(quán)限的服務(wù)，如下圖所示。

圖：線上新建權(quán)限組的交互路徑（優(yōu)化前）

在大多數(shù)場景下，完成一個(gè)權(quán)限組的交互至少要9個(gè)步驟，而且還需要反復(fù)來回切換跳轉(zhuǎn)頁面。而用戶目標(biāo)是給系統(tǒng)用戶同時(shí)設(shè)置多個(gè)服務(wù)的權(quán)限。從用戶體驗(yàn)角度看，設(shè)計(jì)目標(biāo)是幫助用戶高效設(shè)置多個(gè)服務(wù)的權(quán)限。而線上的設(shè)計(jì)模型無法同時(shí)設(shè)置多個(gè)服務(wù)的權(quán)限，無法更高效地匹配用戶的心智模型，所以問題確定是新建權(quán)限的效率比較低。

綜上，我們發(fā)現(xiàn)用戶具體的使用痛點(diǎn)是：管理員在新建權(quán)限組前，每次只能創(chuàng)建一個(gè)服務(wù)的權(quán)限，頁面來回跳轉(zhuǎn)，交互路徑過長，導(dǎo)致管理員在新建權(quán)限組時(shí)花費(fèi)太多時(shí)間，效率比較低，用戶體驗(yàn)不友好。

因此，確定設(shè)計(jì)目標(biāo)是提高管理員新建權(quán)限的效率。

階段二：解決問題

圍繞設(shè)計(jì)目標(biāo)——提高新建權(quán)限的效率，根據(jù)用戶具體的使用痛點(diǎn)，交互路徑長等問題，我們可以縮短其交互路徑，合并單個(gè)服務(wù)權(quán)限的創(chuàng)建，讓管理員一次性設(shè)置所需服務(wù)的權(quán)限，交互步驟縮短至三步完成。所以，變更后的交互方案是用戶新建權(quán)限，批量選擇所需服務(wù)并設(shè)置對應(yīng)權(quán)限，完成權(quán)限創(chuàng)建，步驟如下圖所示。

圖：新建權(quán)限的交互路徑（優(yōu)化后）

依然圍繞設(shè)計(jì)目標(biāo)，再繼續(xù)拆解管理員新建權(quán)限的任務(wù)。我們將管理員新建權(quán)限的任務(wù)過程細(xì)分為選擇服務(wù)前、選擇服務(wù)時(shí)和選擇服務(wù)后三個(gè)行為節(jié)點(diǎn)，構(gòu)思交互方案。

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

權(quán)限業(yè)務(wù)邏輯如下：

• 層級關(guān)系是服務(wù)-集群-應(yīng)用-實(shí)例，應(yīng)用空間與服務(wù)是并列關(guān)系，集群、應(yīng)用、實(shí)例存在多個(gè)的情況。
• 服務(wù)的功能權(quán)限：查詢、增加、刪除、編輯、查看。
• 服務(wù)項(xiàng)56項(xiàng)，有新的服務(wù)時(shí)會(huì)遞增。
• 字段有權(quán)限名稱、描述、服務(wù)項(xiàng)權(quán)限設(shè)置

所以，我們從以上權(quán)限邏輯關(guān)系和數(shù)量范圍，可以確定的是目前服務(wù)數(shù)量是有限的，根據(jù)信息優(yōu)先順序，先展示權(quán)限名稱，再展示服務(wù)權(quán)限設(shè)置，服務(wù)的資源條件使用多選樹狀結(jié)構(gòu)展示，既清晰表達(dá)資源層級關(guān)系，又易于實(shí)現(xiàn)，如下圖所示。

圖：具體服務(wù)的資源條件設(shè)置

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

而用戶找服務(wù)目標(biāo)是明確的，由于服務(wù)名稱多為英文字符，也無法確定哪些是常用服務(wù)，所以考慮列表采用按照服務(wù)名稱首字母A-Z的有序方式排列，使用列表索引方式幫助管理員查找服務(wù)。因?yàn)橛脩粼谡曳?wù)的場景下，主要是依賴服務(wù)名稱查找，找東西本身是有記憶成本的，因此，服務(wù)名稱的定義、列表的排序方式是需要我們設(shè)計(jì)師深入思考的機(jī)會(huì)點(diǎn)，不要讓用戶思考。

當(dāng)用戶選擇服務(wù)時(shí)，只需勾選即可。但是需要考慮點(diǎn)擊區(qū)域和服務(wù)名稱如何展示。選擇服務(wù)后，則需要考慮用戶具體要設(shè)置服務(wù)的哪些權(quán)限，如何設(shè)置具體的權(quán)限？可以根據(jù)大多數(shù)的場景提供默認(rèn)功能權(quán)限的首選項(xiàng)，減少操作，提高效率。

此外，T-PaaS權(quán)限設(shè)計(jì)也使用了RBAC模型，平臺用戶對應(yīng)的就是模型中的用戶，權(quán)限組（權(quán)限集合）對應(yīng)的是角色，服務(wù)項(xiàng)對應(yīng)的是模型中的具體權(quán)限。

小結(jié)：

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

以上即為新建權(quán)限交互優(yōu)化的思考過程和交互體驗(yàn)可思考的設(shè)計(jì)機(jī)會(huì)點(diǎn)，僅拋磚引玉。

三、用戶權(quán)限設(shè)計(jì)原理RBAC模型

以上兩個(gè)權(quán)限設(shè)計(jì)案例，都使用了RBAC（Role-Based Access Control）模型，也是目前B端業(yè)務(wù)系統(tǒng)權(quán)限功能設(shè)計(jì)普遍使用的設(shè)計(jì)模型。

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

圖：RBAC模型及對應(yīng)關(guān)系示意

用戶是指參與系統(tǒng)活動(dòng)的主體 。角色指的是特定權(quán)限的集合，如藍(lán)湖權(quán)限角色超級管理員、編輯者和查看者，每個(gè)角色是被賦予了權(quán)限的集合體。而權(quán)限則是角色對頁面、模塊的具體功能操作和數(shù)據(jù)權(quán)限等，是具體的權(quán)限項(xiàng)，如編輯者可編輯畫布、管理設(shè)計(jì)圖、批注。

權(quán)限具體會(huì)包含頁面權(quán)限、功能操作權(quán)限和數(shù)據(jù)權(quán)限。頁面權(quán)限是指只有特定用戶才有權(quán)限訪問的頁面，例如財(cái)務(wù)可以查看公司的財(cái)務(wù)報(bào)表，而運(yùn)維人員不可以。功能操作權(quán)限，就是用戶對頁面或模塊具有的增刪改查等權(quán)限，比如藍(lán)湖項(xiàng)目文檔，只有項(xiàng)目超級管理員、管理員可以修改文檔，研發(fā)是不可以修改的。而數(shù)據(jù)權(quán)限，就是用戶可查看哪些數(shù)據(jù)。比如集團(tuán)企業(yè)老板可以看到集團(tuán)下各分公司的全部銷售數(shù)據(jù)，而分公司的總經(jīng)理只能看到自己所在分公司的銷售數(shù)據(jù)，其他分公司的銷售數(shù)據(jù)是看不到的。

此外，為了解決更復(fù)雜的權(quán)限業(yè)務(wù)邏輯，RBAC模型也在不斷升級。比如，在角色中引入繼承關(guān)系，把角色分成幾個(gè)等級，每個(gè)等級權(quán)限不同，實(shí)現(xiàn)更細(xì)顆粒度的權(quán)限管理?；蛘?，增加用戶組，管理員直接給用戶組分配角色，再把用戶加入到用戶組，可以批量給更多用戶賦予同一角色的權(quán)限，用戶除了擁有自身的權(quán)限外，還擁有所屬用戶組的所有權(quán)限。

四、總結(jié)

本文主要圍繞B端業(yè)務(wù)系統(tǒng)的功能共性-用戶權(quán)限，通過兩個(gè)權(quán)限設(shè)計(jì)案例，介紹了如何在復(fù)雜權(quán)限邏輯下提升交互體驗(yàn)的方法。具體總結(jié)了12點(diǎn)設(shè)計(jì)心得，幫助大家在做用戶權(quán)限體驗(yàn)設(shè)計(jì)時(shí)，有一些幫助和啟發(fā)。

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

本文由 @沉一 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議