B端產(chǎn)品設(shè)計中的「用戶角色」

本文授權(quán)轉(zhuǎn)載自：騰訊設(shè)計族 （ ID:TencentDesignGroup）

01

前言

作為體驗設(shè)計師，用戶永遠是我們最關(guān)注的部分。對于C端產(chǎn)品，我們常常繪制用戶畫像進行分析；而B端產(chǎn)品由于特有的復(fù)雜業(yè)務(wù)性質(zhì)，用戶更多通過「角色」的概念與系統(tǒng)進行鏈接。因而B端用戶角色的分析對于產(chǎn)品設(shè)計有著更大的意義。

在我近期參與的B端項目中，遇到過這樣的問題：

1. 無關(guān)功能對用戶造成了干擾

有用戶反饋，某CI產(chǎn)品的A功能他并不需要使用，卻占據(jù)了界面的核心模塊，造成了一定的干擾；另一類用戶則表示他只需要A功能，其他完全不關(guān)心，所以覺得現(xiàn)有產(chǎn)品形態(tài)太過復(fù)雜了。

事實上，這兩類用戶的確存在不同的業(yè)務(wù)需求，這決定了他們使用產(chǎn)品時的目標和路徑。B端產(chǎn)品尤其注重效率和目的性，與業(yè)務(wù)無關(guān)的內(nèi)容通常也并不該引起用戶過多關(guān)注，否則將影響用戶的操作流暢度和整體體驗。

2. 不同角色的用戶操作路徑交錯無序

另一款面向游戲營銷活動的管理平臺，也存在類似的問題。盡管平臺劃分了「運營中心」和「開發(fā)中心」兩個模塊，但在經(jīng)歷多輪快速迭代后，有大量運營管理操作雜糅在了開發(fā)中心流程中，并未真正解耦合。這使得運營用戶需要在兩個模塊之間反復(fù)橫跳，操作路徑不清晰。

這些問題都源于前期對用戶的分析不夠透徹，缺少業(yè)務(wù)流程中針對不同用戶的差異化設(shè)計。而「用戶角色」的概念在這里能更明確地定義各類用戶的分工和目標，有效形成業(yè)務(wù)閉環(huán)。

02

關(guān)于用戶角色

根據(jù)拉里·康斯坦丁 (Larry Constantine) 的定義：用戶角色 (User Role) 是一種抽象的概念模型，是對一類用戶及其問題之間關(guān)系的定義，包括需求、興趣、期望和行為模式。

可見「用戶角色」和「用戶」是完全不同的概念、不同的意義——

1. 角色是抽象的，用戶是具體的
2. 角色表示的是一種身份和邏輯關(guān)系，用戶表示的是切實、獨立的個體

角色建立在用戶與問題/業(yè)務(wù)/系統(tǒng)之間，幫助我們概括兩個問題：

① 業(yè)務(wù)需要什么用戶做什么事；② 用戶希望如何完成 Ta 的業(yè)務(wù)。

當(dāng)然，C端產(chǎn)品也有「用戶角色」的概念，只是一般比較寬泛，不會顯式強調(diào)出來這一名詞。

比如教育類 APP，顯而易見就有「講師」和「學(xué)員」兩種角色，只不過在設(shè)計研究中，角色的概念通常直接融入到用戶畫像里進行描述了。

從宏觀意義上，C端與B端的「用戶角色」可以說并無不同，因為不管C端B端，我們都需要通過分析不同角色的目標來有針對性地拆解問題，解決用戶痛點，完成體驗設(shè)計；但從具體的操作思路上，二者還是有區(qū)別的。

我認為一個比較大的區(qū)別在于：

C端用戶角色是「外驅(qū)」的，由外部條件和場景影響用戶行為，從而創(chuàng)造用戶畫像；B端用戶角色則是「內(nèi)驅(qū)」的，是業(yè)務(wù)由內(nèi)而外賦予用戶角色的定義。

如何理解這兩個詞呢？

C端在做體驗分析的時候，更多是通過場景來對用戶進行觀察剖析，然后才會產(chǎn)生相應(yīng)的角色，這些角色很多時候也不會有太明確的邊界。

比如高德地圖的駕車導(dǎo)航最近出了「新手模式」和「標準模式」，產(chǎn)生了「新手司機」和「老司機」兩種角色。其實這一變化就是基于兩種用戶場景給出不一樣的播報體驗，而基礎(chǔ)的用戶目標和設(shè)計策略本質(zhì)上還是一致的。

反觀B端則是以業(yè)務(wù)為核心，由業(yè)務(wù)直接決定了用戶角色的存在和定義，而具體的單個用戶個體我們幾乎不再關(guān)心了，哪怕去做用戶調(diào)研、訪談，視角也是圍繞“這類角色的用戶遇到什么問題、如何解決”等等。

B端的用戶角色具有很強烈的邊界，比如常見的OA審批，提單者和審批者的操作流程完全不一樣，他們的目標也不一樣，前者追求簡單快速，后者追求安全準確，那么設(shè)計時的關(guān)注點也會大大不同。

03

為什么要分析用戶角色

1. 業(yè)務(wù)層面

用戶體驗設(shè)計的根本目標就是解決「用戶」的問題，而B端產(chǎn)品除了面對人，還與復(fù)雜的「業(yè)務(wù)」息息相關(guān)。「用戶角色」常常就是鏈接用戶與業(yè)務(wù)的一種邏輯概念。

正是由于B端產(chǎn)品具有顯著的業(yè)務(wù)特性，設(shè)計師在分析邏輯、處理用戶體驗問題時，首先要明確「業(yè)務(wù)場景」。不同場景下，用戶的體驗?zāi)繕撕腿蝿?wù)路徑有很大差異，這就需要對用戶角色有清晰的認知。

另一方面，設(shè)計師需要有同理心，那么我們對用戶角色進行分析的過程，同時也是我們開始用同理心站在業(yè)務(wù)視角去理解用戶的過程。

用戶角色的分析對于建立心智模型有很大幫助，只有對角色有了充分的理解和認識后，才能產(chǎn)生同理心，做出真正有價值、受人認同的設(shè)計方案。

2. 技術(shù)層面

B端產(chǎn)品中的角色權(quán)限系統(tǒng)是必備的基礎(chǔ)能力，這也使得「用戶角色」在B端的產(chǎn)品設(shè)計中更具研究意義。

這是典型的RBAC權(quán)限結(jié)構(gòu)，源于計算機數(shù)據(jù)庫系統(tǒng)，用來管理用戶在操作使用時的權(quán)限，也就是通過角色來約束哪些用戶能訪問什么、變更什么。

在這里「角色」同樣不是一種「實體」，而是一種「關(guān)系」，它的作用是解耦合。

在計算機的世界里，天然存在「權(quán)限」的課題，因為不可能每個用戶都擁有完全的權(quán)限；而如果沒有角色這個中間層，那么系統(tǒng)管理員需要對每一個來訪用戶單獨配置對應(yīng)權(quán)限，顯然是很低效的做法。

角色就把這層關(guān)系進行了松綁，因為角色是有限的，只要定義了角色所擁有的權(quán)限，無論加入多少用戶都只需賦予其角色即可。另外，當(dāng)權(quán)限分配發(fā)生變化時，也只需對角色進行調(diào)整，不必每個用戶都排查一次，維護成本也大大減少了。

B端常見的權(quán)限中心設(shè)計，必定會接觸到這一邏輯結(jié)構(gòu)。目前大部分的B端平臺也都是采用這套權(quán)限管理機制的，屬于平臺的基礎(chǔ)能力。

某一角色的用戶在平臺中能做什么、怎么做，一定程度上已經(jīng)由權(quán)限系統(tǒng)進行定義和限制，那么設(shè)計師就更應(yīng)該全面掌握各類角色所處的背景，明確業(yè)務(wù)流程中每個環(huán)節(jié)所參與的角色，從他們的視角中挖掘操作體驗的問題。

比如常見的運營SaaS平臺中會有「開發(fā)者」和「運營者」兩種角色。哪怕在同一業(yè)務(wù)場景中，這兩種角色的用戶認知習(xí)慣和操作流程都會不同，設(shè)計師就需要針對角色的目標進行深入分析。

由此可見，相比C端，在B端的體驗設(shè)計中將更有必要面向「用戶角色」進行設(shè)計分析。

04
用戶角色有哪些特征

作為一種技術(shù)性的抽象模型，用戶角色有別于人物模型或用戶畫像 (Personas)。人物模型是一種比喻模型，它們被構(gòu)造為類似真實的用戶，更像身邊的普通人。而用戶角色是抽象屬性的集合，通過背景、特征和指標來綜合表現(xiàn)。

具體而言，人物模型會盡可能真實地描述一名用戶的性別、年齡、所在城市和日常習(xí)慣偏好；而用戶角色則并不糾結(jié)這些細節(jié)，而是把構(gòu)建的精力放在業(yè)務(wù)特性中，沿著關(guān)鍵決策鏈來劃分用戶群體。

那么，結(jié)合理論資料及B端領(lǐng)域的實踐經(jīng)驗，我歸納了「用戶角色」的如下三個特征：全覆蓋、差異化和收斂性。

1.全覆蓋

覆蓋，指的是用戶角色的覆蓋范圍。我們在初期對角色進行分組定義時，必須涵蓋系統(tǒng)中的每一類角色，從而保證業(yè)務(wù)閉環(huán)的完整性，避免流程斷裂而跑不下去。

比如上圖所示三種角色，他們共同完成了產(chǎn)品上線所需的三個核心環(huán)節(jié)，缺一不可。

再比如開篇提到的開發(fā)運營工具，我們知道顯然存在「開發(fā)者」和「運營者」兩種角色，但除此之外，經(jīng)過洞察會發(fā)現(xiàn)還會有部分用戶屬于「測試人員」或「產(chǎn)品經(jīng)理」，同時也必定會有各級別「管理員」權(quán)限的角色。所有這些角色的配合才能構(gòu)成完整業(yè)務(wù)的協(xié)作流，而每個角色所處的環(huán)節(jié)都是設(shè)計師需要換位分析的。

因此，設(shè)計師需要在分析問題之前先明確所有角色，保證全面覆蓋到業(yè)務(wù)。

2.差異化

用戶角色與人物模型的其中一個鮮明區(qū)別，就在于用戶角色有著更為明確的邊界。由于業(yè)務(wù)分工的明確性，也由于系統(tǒng)權(quán)限的客觀定義，角色和角色之間定有比較清晰的分界線，使得用戶目標、操作流程等都存在顯式的差異化。

比如騰訊英語君通過初次使用時選擇身份來提供差異化的服務(wù)，讓不同角色的用戶能更快更好地達成他們使用APP的目標。

又比如我最近參與的CI產(chǎn)品，兩類用戶對于產(chǎn)品的訴求完全不同，正是因為他們的角色有明確的業(yè)務(wù)分工，需要完成的任務(wù)有差異性，因此需要針對他們所處的場景和目標，具體問題具體分析，定制符合各自預(yù)期的體驗方案。

3.收斂性

我們知道，C端產(chǎn)品在做人物模型會盡可能豐富地展現(xiàn)用戶的多面性，以發(fā)散的視角去還原一個「真實的人」。但B端分析用戶角色時明顯相反，受限于業(yè)務(wù)的既定范圍，用戶角色天然具備收斂性；簡言之：B端用戶一般不會進行與其角色目標無關(guān)的操作，也不太會有額外的個性化的想法。

好比一款OA系統(tǒng)，普通員工一般無法進行審批，所以審批相關(guān)的操作流程不需要引起他們關(guān)注；而即便是審批者或管理員，在這個系統(tǒng)中也不會憑空希望增加評價功能的體驗，或增強審批過程的趣味性，因為他們角色的業(yè)務(wù)目標是高效準確地完成批復(fù)。

05
如何針對用戶角色進行設(shè)計

B端產(chǎn)品中，角色定義通常已經(jīng)由業(yè)務(wù)所決定，但我們在設(shè)計中仍然需要關(guān)注各角色的特點和任務(wù)目標，可通過同理心地圖等研究工具進行拆解分析，解決不同用戶路徑中存在的體驗問題。

1. 業(yè)務(wù)邊界

站在內(nèi)部視角，我們知道用戶角色是源于自身業(yè)務(wù)屬性的。不同角色之間體現(xiàn)了差異性，也就存在較為明確的業(yè)務(wù)邊界。當(dāng)我們能清楚劃分這些邊界時，我們也就可以梳理出某一角色在某一場合下既定的操作流程。

那么，設(shè)計師需要做的就是結(jié)合這些業(yè)務(wù)特性，確定各角色的用戶能做什么、不能做什么，從而排除冗余的信息和操作，提高信噪比，聚焦任務(wù)目標。

我比較常用的工具是泳道流程圖，在一些多角色協(xié)作的業(yè)務(wù)場景中，泳道的分隔線就提供了直觀的邊界，我們可以清晰梳理出協(xié)作的每一個環(huán)節(jié)，以及每個角色所關(guān)注的信息。

以前面提及的CI產(chǎn)品為例，第一類用戶的業(yè)務(wù)操作不涉及A功能模塊，但第二類用戶反而以A功能為核心任務(wù)，這就是角色之間的差異性。當(dāng)我們清楚了解這些邊界之后，就可以尋求更優(yōu)的方案，使用戶不被過多無關(guān)信息所干擾，操作流程就會更聚焦也更順暢。

2. 同理心地圖

站在外部視角，帶著用戶的眼光進行審視，我們可以運用同理心地圖等用戶研究工具，代入角色去了解目標用戶。

但值得注意的是，「同理心」對于抽象的角色模型其實是不起作用的。所以我們?nèi)匀恍枰谟脩艚巧A(chǔ)上進一步開發(fā)出人物模型，多維度表現(xiàn)用戶目標及復(fù)雜行為模式，為同理心地圖提供更全面具體的情境。

來源：《Updated Empathy Map Canvas》——Dave Gray

在《About Face》中也提到，用戶角色是抽象概念，也存在著局限性。

換言之，我們在審視用戶角色的時候，并不會認為那就是一個具體的人、一個真實的用戶。所以它并不等同于用戶畫像。

那么我們在B端項目中進行了用戶角色分析后，仍然有必要結(jié)合具體的場景和行為進行討論。比如，同一個用戶很有可能同時屬于「開發(fā)者」和「項目管理員」，那么他的訴求將會更為具體也更為復(fù)雜。

06
案例淺析

那么，對于開篇提到的兩款產(chǎn)品，在設(shè)計分析階段如何找到切入點呢？

案例一：

一款CI產(chǎn)品，集成了測試自動化、運維可視化的代碼交付部署平臺，并能幫助業(yè)務(wù)上線前高效收集體驗反饋。

產(chǎn)品分為兩大功能模塊：代碼部署的流水線管理、業(yè)務(wù)內(nèi)測安裝體驗，由此產(chǎn)生兩大類用戶：開發(fā)運維用戶、產(chǎn)品體驗用戶。

問題就在于，目前移動端的信息架構(gòu)劃分了四個板塊，A作為首頁，推送的都是與B板塊相關(guān)的產(chǎn)品體驗內(nèi)容，而只有C是面向運維的流水線管理功能。于是就收到了前述的一些用戶反饋。

為什么會出現(xiàn)這樣的問題呢？因為產(chǎn)品在迭代過程中只是粗暴地堆砌功能，沒有先對用戶角色進行拆解分析，于是所有的用戶都看到完全一樣的信息，卻并不是他們最想看到的內(nèi)容。

于是我從「收斂性」的角度進行用戶分析，找準不同角色的目標。

結(jié)合反饋和進一步訪談結(jié)論，可以定位到一個關(guān)鍵的問題：缺少針對不同用戶角色的APP首頁差異化設(shè)計。因無法將不同用戶快速引流到他們預(yù)期的功能板塊，從而阻礙了他們處理業(yè)務(wù)的操作流程。

針對這一問題，可以將設(shè)計目標定義為「精準」——讓用戶在自身角色場景下更輕松、更準確地找到當(dāng)前需要處理的任務(wù)。

通過用戶分層設(shè)計，減少與角色無關(guān)的信息干擾。開發(fā)運維用戶的業(yè)務(wù)操作不涉及A、B功能模塊，但業(yè)務(wù)體驗用戶反而以A功能為核心任務(wù)，這就是角色之間的差異性。當(dāng)我們清楚掌握這些邊界之后，就可以尋求更優(yōu)的方案，使用戶不被過多無關(guān)信息所干擾，操作流程就會更聚焦、更順暢。

案例二

面向游戲營銷活動的開發(fā)運營平臺，通過統(tǒng)一的自研的前端開發(fā)框架，實現(xiàn)游戲項目內(nèi)嵌的運營活動，使不同游戲業(yè)務(wù)都能復(fù)用相同的開發(fā)資源，快速發(fā)布、運營游戲內(nèi)營銷活動。

這個項目處于快速迭代功能的階段，也就是先后追加功能模塊的過程。在這個過程中就出現(xiàn)了“熵變”，信息架構(gòu)越來越混亂無序。主要體現(xiàn)在平臺的兩個主要板塊：運營中心和開發(fā)中心。

從字面可以理解，兩個板塊分別面向運營人員和開發(fā)人員。然而，當(dāng)前運營中心里只有運營數(shù)據(jù)以及第三方運營平臺的入口，而運營人員日常高頻操作的應(yīng)用發(fā)布、管理，卻全部集中在開發(fā)中心里。

造成這一困擾的原因也是初期追求快速迭代，希望將開發(fā)中心已實現(xiàn)的一套功能直接對運營人員開放，協(xié)同完成開發(fā)和發(fā)布。

而后果就是，運營人員需要在兩個板塊間反復(fù)橫跳，操作路徑無序又冗長；而且大多數(shù)情況下需要深入到看起來與角色無關(guān)的開發(fā)中心里管理他們的運營業(yè)務(wù)，顯然對新手非常不友好。

從用戶角色的「差異化」入手，通過對角色分析和信息架構(gòu)的重新梳理，可以得到設(shè)計目標就在于「聚焦」——依托業(yè)務(wù)邊界，使用戶聚焦關(guān)注自身角色的業(yè)務(wù)流程。

前面提到用戶角色具有業(yè)務(wù)邊界，那么邊界外的信息就應(yīng)該盡量減少，從而提高認知和操作效率。

進一步推導(dǎo)設(shè)計策略：通過對運營人員角色的流程疏導(dǎo)，整合搭建運營中心的信息架構(gòu)，將運營業(yè)務(wù)從開發(fā)中心中抽離，從而簡化運營操作路徑。

07
總結(jié)

「當(dāng)(某角色)用戶使用產(chǎn)品某項功能的時候，他們是為了完成某個特定的任務(wù)(到達某種目標)」

一旦理解了這句話，并在設(shè)計過程中切實圍繞場景、角色、目標去深入分析，我們的設(shè)計方案將會更有效地解決體驗問題、提高業(yè)務(wù)效率。