干貨總結(jié):B端業(yè)務(wù)系統(tǒng)用戶權(quán)限交互可用性設(shè)計

誠俊
2 評論 17170 瀏覽 91 收藏 20 分鐘

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

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

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

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

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

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

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

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

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

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

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

圖:Figma 項目成員權(quán)限設(shè)置

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

2.1 案例一:藍(lán)湖項目權(quán)限交互設(shè)計

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

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

圖:藍(lán)湖項目團(tuán)隊權(quán)限設(shè)置

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

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

小結(jié):

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

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

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

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

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

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

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

階段一:問題診斷

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

圖:模型匹配

用戶心智模型分析:

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

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

線上設(shè)計模型分析:

線上的權(quán)限設(shè)計是引入權(quán)限組,權(quán)限組關(guān)聯(lián)具體的服務(wù)權(quán)限項設(shè)置,但是權(quán)限組和具體的服務(wù)權(quán)限是分開創(chuàng)建的。具體交互路徑是:管理員新建權(quán)限時,每次只能選擇單個服務(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ù)場景下,完成一個權(quán)限組的交互至少要9個步驟,而且還需要反復(fù)來回切換跳轉(zhuǎn)頁面。而用戶目標(biāo)是給系統(tǒng)用戶同時設(shè)置多個服務(wù)的權(quán)限。從用戶體驗角度看,設(shè)計目標(biāo)是幫助用戶高效設(shè)置多個服務(wù)的權(quán)限。而線上的設(shè)計模型無法同時設(shè)置多個服務(wù)的權(quán)限,無法更高效地匹配用戶的心智模型,所以問題確定是新建權(quán)限的效率比較低。

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

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

階段二:解決問題

圍繞設(shè)計目標(biāo)——提高新建權(quán)限的效率,根據(jù)用戶具體的使用痛點,交互路徑長等問題,我們可以縮短其交互路徑,合并單個服務(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è)計目標(biāo),再繼續(xù)拆解管理員新建權(quán)限的任務(wù)。我們將管理員新建權(quán)限的任務(wù)過程細(xì)分為選擇服務(wù)前、選擇服務(wù)時和選擇服務(wù)后三個行為節(jié)點,構(gòu)思交互方案。

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

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

  • 層級關(guān)系是服務(wù)-集群-應(yīng)用-實例,應(yīng)用空間與服務(wù)是并列關(guān)系,集群、應(yīng)用、實例存在多個的情況。
  • 服務(wù)的功能權(quán)限:查詢、增加、刪除、編輯、查看。
  • 服務(wù)項56項,有新的服務(wù)時會遞增。
  • 字段有權(quán)限名稱、描述、服務(wù)項權(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)系,又易于實現(xiàn),如下圖所示。

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

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

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

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

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

小結(jié):

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

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

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

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

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)活動的主體 。角色指的是特定權(quán)限的集合,如藍(lán)湖權(quán)限角色超級管理員、編輯者和查看者,每個角色是被賦予了權(quán)限的集合體。而權(quán)限則是角色對頁面、模塊的具體功能操作和數(shù)據(jù)權(quán)限等,是具體的權(quán)限項,如編輯者可編輯畫布、管理設(shè)計圖、批注。

權(quán)限具體會包含頁面權(quán)限、功能操作權(quán)限和數(shù)據(jù)權(quán)限。頁面權(quán)限是指只有特定用戶才有權(quán)限訪問的頁面,例如財務(wù)可以查看公司的財務(wù)報表,而運維人員不可以。功能操作權(quán)限,就是用戶對頁面或模塊具有的增刪改查等權(quán)限,比如藍(lán)湖項目文檔,只有項目超級管理員、管理員可以修改文檔,研發(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)系,把角色分成幾個等級,每個等級權(quán)限不同,實現(xiàn)更細(xì)顆粒度的權(quán)限管理?;蛘?,增加用戶組,管理員直接給用戶組分配角色,再把用戶加入到用戶組,可以批量給更多用戶賦予同一角色的權(quán)限,用戶除了擁有自身的權(quán)限外,還擁有所屬用戶組的所有權(quán)限。

四、總結(jié)

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

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

 

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 使用這個模型設(shè)計的權(quán)限,想看個人對應(yīng)哪些權(quán)限需要考慮什么?
    想要做個導(dǎo)出的功能

    來自北京 回復(fù)
  2. 把紛繁復(fù)雜的繼承后臺,抽象化為具體的職位需要的權(quán)限,以角色來進(jìn)行配置,還是挺不錯的想法,
    但是對于大型的集成系統(tǒng),是否應(yīng)該加入角色配置的功能,進(jìn)行更進(jìn)一步的細(xì)分
    1配置角色
    2配置角色權(quán)限
    3設(shè)置用戶角色
    有個2中間層的存在會靈活并且方便很多

    來自廣東 回復(fù)