編輯導讀：隨著B端產品需求量與日俱增，B端市場的春天也逐漸到來，在這過程中B端體驗設計變得越來越受到重視。面對挑戰，設計師的設計思路該是怎樣的？本文作者對 B 端產品體驗設計方法——角色全景圖展開了分析說明，供大家一起參考和學習。
01 研究背景
1. ToB產品的發展正在帶動體驗設計訴求
近年來湧現了不少優秀的B端產品，讓人們開始意識到好的設計對產品的增益。對於CRM、ERP、工單平臺這類複雜工具類系統，人們不再只是追求功能基本跑通、界面是否好看，也開始關注產品是否清晰好用、能否快速上手、能否降低人工勞動、能否提升工作效率…
對於前者，不少團隊通過「設計系統(Design System)」來解決一致性、美觀度、可用性、開發效率等問題。而對於後者，如何讓B端產品更貼合使用者的工作場景和體驗訴求，也成了設計師日益關注的重心。
2. 個人賽與團體賽的差異
在C端產品中，設計師與用戶離得近，更容易與用戶共情。我們可以用各類定性方法挖掘用戶場景，用業務數據來分析轉化漏鬥。
而在B端產品中，設計師需要面對複雜多樣的利益相關者、盤根錯節的業務流程。而且不同階段的B端產品，它的數據完備性也有所差異，例如一些從0到1、僅供內部運營人員使用的後臺系統就沒有豐富數據或者完整的行為埋點。
賽制差異
就像個人田徑賽和團體接力賽，個人賽制僅需要關心單個運動員如何突破他自己的成績極限，而團體賽制就需要關心不同成員的實力水平、接棒順位和接棒配合等問題。因此原本C端很好用的研究方法就有些水土不服，需要設計師作出適當的調整和革新。
02 設計方法的借鑑與演變
我們對常用的體驗度量模型、用戶分析框架進行分析與研究，並在「職級評審系統」中進行應用實踐。
（1）HEART-GSM框架：以5個維度去衡量用戶體驗的模型框架，並根據維度拆解對應的業務指標。在剖析了模型的運用原理後發現，維度未必是一成不變的，而是可以根據業務方向去定義和調整。業務指標也是由定位好的方向目標進行拆解。那麼，在「職級系統」中就可以獲得如下解析：
職級系統的GSM分析（局部）
（2）TECH模型：由螞蟻金服團隊提出的企業級產品度量模型。在它四個指標中我們找到了一個比較關鍵的核心：角色的任務成功率，通過體驗地圖描繪系統角色的核心任務流，從中測評系統對角色的效率、體驗影響。
（3）CES客戶費力度：用來描述客戶需要花費多少力氣來達成他的任務目標。比起滿意度而言，費力度更能直觀反應工具類產品的使用體驗，避免出現「我很滿意，產品不好用」的尷尬。
綜合分析後，我們漸漸發現了苗頭——或許可以織一張三維畫布，在業務方向的基礎上建立流程、角色、費力度之間的聯繫。於是，我們打算從這三個角度，復刻每個角色任務歷程（線下、線上、系統載體、信息傳遞），度量其任務費力點，洞察他們與系統效率之間的關係。
職級系統的體驗分析框架
03 建立「角色全景圖」
經過前期的研究和分析，我們明確了業務目標、評估訴求、流程場景、核心任務角色等幾類要素，接著需要對系統每個角色的任務和對應的費力度評估進行梳理。
1. 角色任務梳理
根據業務流程，我們劃分了從募集評委到申訴環節等8個業務階段。在此基礎上我們採用頭腦風暴、定性訪談的方式，逐步完成了五類角色任務流程的採集與布點。
角色任務節點梳理
為了更高效地梳理任務泳道，我們定義了任務流程的兩個關鍵基準：
任務節點：推動流程往下進行的節點才做記錄。而任務之內的個人操作、細分任務都不做節點拆分，為的是抓住關鍵流程，呈現成功路線。交棒時刻：複述用戶在完成任務後向他人、向系統傳遞信息的動作內容。我們發現在線下遞交材料、或系統任務提交過程中有時間交錯的情景，因此單獨剝離交棒時刻，為的是復刻用戶的信息傳遞過程。在此之上，融入了業務目標，明確標記角色任務所運用的載體、方式、工具，以便梳理系統線上化率。
2. 角色任務下鑽評估
在獲取每類角色的任務泳道之後，我們可以針對性地進行體驗下鑽——評估任務節點的費力度與任務內容等問題。因為在梳理環節掩蓋了節點之內的角色使用體驗。下鑽評估是為了更好地補足角色任務細節，了解到單個角色的任務影響因子，從而建立更全局的體驗認知。
角色體驗下鑽評估
實操過程中，系統的任務節點可能會有幾十上百個。此時未必追求面面俱到，可以通過角色的代表性人物，定位關鍵任務節點，然後再用定性+定量的方式下鑽研究，獲取該節點處所反應的費力度、問題分布、任務強度特徵。接著可以用可視化的方式表達任務節點的費力度等級、角色體驗評估內容，然後匯總成角色全景圖。
角色全景圖合集
04 進行「全景圖」觀察
在完成了全景圖的梳理和繪製之後，我們便可以俯瞰全局，獲取系統性的設計洞察。
1. 任務點觀察
前期設置的任務節點、交棒時刻、動作載體，均是為了觀察者能夠進行閱讀、統計和觀察。通過節點信息可以了解到整個系統流程的任務內容和信息傳遞方式。
匯聚提煉後，我們梳理出全部的角色觸達場景池，挖掘了21處信息互動節點，比原計劃落地的功能多了18處，彌補了單向研發過程中的盲點，為後續的迭代指明了優化方向。
任務點觀察
2. 任務面
根據角色泳道的下鑽評估，我們可以看到用戶的費力等級分布，關注任務點相連的上下遊鏈路和系統流程，從立體的角度找到改進空間。
例如，職級系統需要實現上百場評審活動的場次分配，關聯著組織者、評委、參評人和主管等多位角色的時間地點安排。系統在完成了自動化的場次分配之後，還需要組織者口頭確認評委們的時間安排，以保障評審正常進行。
在這任務下鑽過程中，發現組織者需要在這環節需要承擔很多人力成本，任務量大、耗時多、溝通過程反覆低效，系統在這流程階段中還存在需要改進的空間。因此我們可以改進組織者的場次分配方式，建立評委的信息回複流程，從而實現效率的提升。
還有很多類似的觀察幫助我們找到了系統改進方向，在此不一一枚舉。而且全景圖不僅幫助了設計師，還同樣幫助了上下遊的合作夥伴，讓項目成員對整個系統的流程體驗有了統一的共識。
05 寫在最後
回歸出發點，我們希望通過角色全景圖，讓設計師能夠在B端複雜系統中建立全局業務感知，從而更好地發揮主觀能動性。而這方法還只是初始版本，具體的適用範圍、操作方式等還需要更多的實踐來檢驗，我們也開始在其他項目中運用此項方法，後續可以期待更新的研究結果。
總的來說，角色全景圖本質上還是源自常規體驗地圖、服務藍圖的演變。無論是何種可視化圖表，都是以某種方式表示價值創造。如今To B領域愈發蓬勃發展，更需要我們以一種建設性的全新視角去重新認識已知的方法體系。
作者：蔡陽明，互動設計師
本文來源於人人都是產品經理合作媒體@58用戶體驗設計中心（微信公眾號@58UXD），作者@蔡陽明
題圖來自Unsplash，基於CC0協議