1. 前言

作為體驗設計師，用戶永遠是我們最關注的部分。對于 C 端產品，我們常常繪制用戶畫像進行分析；而 B 端產品由于特有的復雜業務性質，用戶更多通過「角色」的概念與系統進行鏈接。因而 B 端用戶角色的分析對于產品設計有著更大的意義。

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

無關功能對用戶造成了干擾

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

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

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

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

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

2. 關于用戶角色

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

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

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

角色建立在用戶與問題/業務/系統之間，幫助我們概括兩個問題：

① 業務需要什么用戶做什么事；② 用戶希望如何完成 Ta 的業務。

當然，C 端產品也有「用戶角色」的概念，只是一般比較寬泛，不會顯式強調出來這一名詞。

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

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

我認為一個比較大的區別在于：

C 端用戶角色是「外驅」的，由外部條件和場景影響用戶行為，從而創造用戶畫像；B 端用戶角色則是「內驅」的，是業務由內而外賦予用戶角色的定義。

如何理解這兩個詞呢？

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

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

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

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

3. 為什么要分析用戶角色

業務層面

用戶體驗設計的根本目標就是解決「用戶」的問題，而 B 端產品除了面對人，還與復雜的「業務」息息相關。「用戶角色」常常就是鏈接用戶與業務的一種邏輯概念。

正是由于 B 端產品具有顯著的業務特性，設計師在分析邏輯、處理用戶體驗問題時，首先要明確「業務場景」。不同場景下，用戶的體驗目標和任務路徑有很大差異，這就需要對用戶角色有清晰的認知。

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

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

技術層面

B 端產品中的角色權限系統是必備的基礎能力，這也使得「用戶角色」在 B 端的產品設計中更具研究意義。

這是典型的 RBAC 權限結構，源于計算機數據庫系統，用來管理用戶在操作使用時的權限，也就是通過角色來約束哪些用戶能訪問什么、變更什么。

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

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

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

B 端常見的權限中心設計，必定會接觸到這一邏輯結構。目前大部分的 B 端平臺也都是采用這套權限管理機制的，屬于平臺的基礎能力。

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

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

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

4. 用戶角色有哪些特征

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

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

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

全覆蓋

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

比如上圖所示三種角色，他們共同完成了產品上線所需的三個核心環節，缺一不可。

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

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

差異化

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

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

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

收斂性

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

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

5. 如何針對用戶角色進行設計

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

業務邊界

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

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

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

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

同理心地圖

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

但值得注意的是，「同理心」對于抽象的角色模型其實是不起作用的。所以我們仍然需要在用戶角色基礎上進一步開發出人物模型，多維度表現用戶目標及復雜行為模式，為同理心地圖提供更全面具體的情境。

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

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

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

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

6. 案例淺析

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

案例之一是一款 CI 產品，集成了測試自動化、運維可視化的代碼交付部署平臺，并能幫助業務上線前高效收集體驗反饋。

產品分為兩大功能模塊：代碼部署的流水線管理、業務內測安裝體驗，由此產生兩大類用戶：開發運維用戶、產品體驗用戶。

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

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

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

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

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

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

案例二是面向游戲營銷活動的開發運營平臺，通過統一的自研的前端開發框架，實現游戲項目內嵌的運營活動，使不同游戲業務都能復用相同的開發資源，快速發布、運營游戲內營銷活動。

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

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

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

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

從用戶角色的「差異化」入手，通過對角色分析和信息架構的重新梳理，可以得到設計目標就在于「聚焦」——依托業務邊界，使用戶聚焦關注自身角色的業務流程。
前面提到用戶角色具有業務邊界，那么邊界外的信息就應該盡量減少，從而提高認知和操作效率。

進一步推導設計策略：通過對運營人員角色的流程疏導，整合搭建運營中心的信息架構，將運營業務從開發中心中抽離，從而簡化運營操作路徑。

7. 總結

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

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

歡迎關注作者微信公眾號：「騰訊設計族」