網易UEDC – 盧小飛：隨著互聯網常規 C 端業務逐漸由藍海轉為紅海，易變現的業務類型漸趨穩定，一方面 C 端互聯網業務本身快速更迭淘汰，而另一方面業務的深度和市場需求的發掘漸趨緩慢，在此趨勢下，互聯網從業者努力地尋找 C 端業務新的增長點。與此同時，各大廠紛紛部署 B 端業務，而 B 端用戶體驗設計因其業務尚是一片藍海，且由于自身的特點，所以具有較高的業務門檻和業務深度的持續可挖掘性。

面對突如其來的 B 端體驗設計的挑戰，設計師該如何應對？或者說設計師的思路該如何針對 B 端設計的特點進行調整？甚至設計管理的思路如何調整？帶著這些問題，讓我們先梳理出線索，分析在工作中遇到的實際挑戰，再逐步尋找成體系的應對方法。

來自B端設計的各種挑戰

無論是從市場上一些頗有見地的分析比較 B 端、C 端設計的文章來看，還是從工作中實際遇到的問題來分析，從 B 端體驗設計的每個環節中，都能強烈地感覺到 B 端體驗設計遇到的挑戰，其中感受最深也最難跨越的，當屬同理心挑戰。

1. 挑戰1：同理心挑戰

C 端產品中，交互設計師的任務是發現用戶需求，定義用戶價值，解決用戶在使用場景中的痛點，并推動項目達成這一目標。作為交互設計師，同理心正是我們發現用戶需求，模仿用戶行為，揣摩用戶意圖，鎖定用戶目標，解決用戶痛點的法寶，我們之所以可以這么做，是因為在 C 端用戶體驗的設計中，交互設計師大部分情況下都或多或少地就是用戶本身，或者帶有用戶屬性。

△ 同理心挑戰

B 端產品，是根據客戶的戰略或服務于線下已有的流程，構建生態體系，推動將流程系統化，管理數據資產，獲取核心的生產經營數據，提高生產經營效率，幫助企業決策。一般情況下，交互設計師的 B 端產品的用戶屬性往往無限趨近于零。以市場上常見的 B 端產品為例：

• 財稅系統 FI（Financial Institution）：財務、費用、差旅等相關系統，相關企業有金蝶、用友等；
• 辦公自動化 OA（Office Automation）：協同工作，提高效率，相關企業有釘釘、Teambition等；
• 客戶關系管理 CRM（Customer Relationship Management）：相關企業有銷售易、紛享銷客；
• 人力資源 HR（Human Resource）：HR 管理系統，人員信息，業績評定，薪酬考勤，招聘升職的管理系統，比如各大公司的 HR 管理系統；
• 企業資源計劃 ERP（Enterprise Resource Planning）：包括企業的生產資源計劃、制造、財務、銷售、采購等功能，如 SAP 中國；
• 云計算（Cloud Computing）：云計算即以互聯網為中心，在網站上提供快速且安全的云計算服務與數據存儲的平臺，國內的相關企業有阿里云、騰訊云、網易云等；
• 大數據（Big Data）：大數據是規模大到在獲取、存儲、管理、分析方面大大超出了傳統數據庫軟件工具能力范圍的數據集合，相關企業有網易大數據、Google Analytics 等；
• 醫療類產品（Healthcare）：面向醫務工作者的工作平臺，相關企業如 Varian；
• 物流平臺（logistics）：解決現代企業物品流通的所有物流需求的平臺，比如京東物流、阿里菜鳥等；
• 內容管理系統 CMS（Content manage system）：企業或政府內部用于信息管理、信息發布和網站維護的內容管理和發布應用系統，比如網易云的 CMS 系統。

△ 市場上常見的B端業務

考察以上的業務類型，可以說交互設計師平時除了在財稅系統和 OA 系統有一部分報銷或者工作協同使用需求外，其他幾乎什么都挨不著邊，更不要說專業挑戰巨大的醫療系統，技術挑戰很大的云計算和大數據系統了。實際工作中，尤其是在剛剛開始從事 B 端交互設計，越是設計類出身的交互設計師，越是會體會到一種無從下手的感覺，很大一部分設計基本思路都是產品和開發告知的，因此也難免會產生一種無力感。

因此，如果將 B 端交互業務分為幾個象限的話，越是處在右下方的產品，對大部分交互設計師的門檻越高。

??

△ 象限分析

要更好地理解B端業務，沒有其他的應對辦法，必須認真做好以下兩點。

謙虛踏實地學習業務

以云計算大數據為例，首先要吃透自己手里的設計工作的業務細節，向產品和開發同事詳細了解產品的需求，弄清每個步驟的業務邏輯，甚至開發的實現模型，測試對細節的要求等等。在確認需求的環節，當需求方希望你把一些較為難于理解的業務，設計成某種他希望的樣式時，一定要將業務邏輯理解透徹再考慮應該如何進行設計實現。要問問為什么業務流程是這樣，為什么用這幾個菜單，這個填代碼的區域，要用戶填的是什么意義的代碼，列表的每一列的含義是什么，詳情的每個指標說明了什么含義？自己要清楚知道整個頁面里的每個控件，控件的每個選項的業務含義是什么。要探討流程的業務合理性，越是復雜有爭議就越要盡量多提供幾套方案以供討論。要斟酌用詞是否清晰和正確，陳述是否專業嚴謹又易于理解，盡量少帶語氣等等。

做好用戶調研工作

積極地與用戶接觸，參與或組織用戶調研。用戶可以請多名用戶做訪談，做好訪談腳本，了解現有設計有哪些痛點。這些真實的痛點，往往是產品、架構師無法預料的。

舉例來說，在云計算業務由面向小 B 用戶到大 B 用戶的轉變過程中，通過對目標用戶的深入訪談，了解到現有的云計算產品實現對大 B 用戶來說，除了存在一些普通的共性體驗問題之外，還存在大量的批量操作問題，批量刪除，批量啟動，批量查找，批量顯示等，是需求確認的。

2. 挑戰2，目標用戶的挑戰

C 端產品的用戶往往就是購買者，而且用戶往往數量眾多，有時可以達到數億的規模，這種情況下，用來進行用戶畫像建模的數據量大，所以用戶畫像比較精準，細分的用戶畫像都能比較方便地建立起來。

實際工作中發現，B 端產品的用戶數量比較有限。更重要地，用戶往往不是客戶，而是一個組織，，包括決策者，管理者和執行者三個維度。其中決策者是客戶，而管理者和執行者是不同角色的用戶。決策者作為 B 端產品的客戶，并不一定需要經常使用產品，但決定是否購買產品。因此，在客戶這個層面，要從企業管理的層面去理解客戶的需求，考慮產品能否幫助客戶理順管理流程，提高效率，節約成本，獲得穩定安全的資源，提高客戶的購買意愿。而針對管理者和執行者的用戶層面，由于需要滿足不同角色間的生產協作需求，滿足不同層級和組織內外的協同溝通需求，因此在具體設計操作層面，要做好不同層級的用戶畫像，為不同層級的用戶提供必需的使用權限，根據用戶的分級去做好每一級用戶的體驗設計。

由于系統的復雜，在執行者這個層面，也往往存在很多不同的角色，不同角色間同樣有不同的需求，在設計中要分辨清楚，協調好解決方案。

舉例來說，在大數據產品中，數據開發和數據分析師，都是大數據系統的用戶，但是他們的需求有一定的差異。在搜索表的時候，數據開發更關心自己常用的收藏表和項目內的公共表，而數據分析師并不關心固定的表，但是關心他瀏覽過的表的記錄。因此，在提供表搜索的設計時，要把這兩個層面的需求同時考慮進去，也就是說如何在同一個頁面，設計能同時滿足兩種不同的需求，以便數據開發工程師和數據分析師都能方便地使用產品。

△ 角色分析

關于目標用戶的確認，在具體的實踐中還往往出現以下一些問題，是在設計分析階段要盡量避免的。

問題一：為自己設計

一些軟件相關專業出身的設計師比較能理解一些底層的業務邏輯，但實際上他們并非真正的用戶。這部分設計師存在自己制定框架制定規矩，讓用戶在此框架里玩的想法，但不去理解用戶到底想要什么。當用戶明確提出體驗問題時，又從實現模型出發認為設計就應該是那樣的，不愿也不應該尋找替代的設計，導致用戶易用性受到非常嚴重的影響。這種設計不是以用戶為中心的，而是以設計師本人為中心的，極不可取。

問題二：為程序員而設計

出現這種問題，原因往往是設計師過分認同開發工程師的意見，同時認為 B 端產品一些交互需求的實現會影響開發工作量，特別是底層的開發工作量有可能會變得巨大，因此對開發工程師強調的事情一概言聽計從，但是遇到用戶體驗的問題也不愿意迭代，認為二次返工會導致開發工作量變大，也不符合開發的想法。

問題三：單純為用戶而設計

從用戶的口中往往可以收集到很多問題，尤其是大客戶的用戶反饋，有很多的要求甚至抱怨。此時要求產品經理和交互設計師通力合作，制定出清晰的產品路線圖，為每一次升級迭代指引出方向。而不是用戶怎么說就怎么改，過幾天聽到其他用戶反饋可能又迷惑是不是再改回去，失去了對產品主線的清晰把握，這樣的交互往往會改成四不像。

3. 挑戰3，設計標準的挑戰

B 端交互的產品設計，由于有著清晰的目的性，比如財務系統類、協同操作類、云計算大數據類、工業互聯網類等等 B 端業務的體系，都有著清晰的操作目的，它們顯然都不是帶著用戶漫無目的地遨游互聯網，或者消磨時間，或者滿足虛榮心，或者發泄情緒，或者滿足用戶其他的欲望，而是有清晰精準的業務目標，因此「效率第一」就成為 B 端交互設計的第一標準。追求花里胡哨的用戶界面，超出主線的附加用戶功能，過分情感化的體驗設計，都不應該是 B 端交互需要遵從的設計標準。

根據以往經驗的總結，拆解到具體的 B 端交互設計上，是要求設計師做到以下幾點。

功能清晰，模塊劃分準確

功能模塊分類清晰，用戶一目了然，減少學習成本。

交互流程精準，切合業務實際場景

各步驟之間銜接自然流暢，精準切合業務實際的流程。

體驗統一而有序

使用相同的控件，保持體驗的一致性。

用戶理解簡約通俗

設計時所用的語言和一些使用習慣應該盡可能與目標用戶熟悉的行為保持一致，以提高用戶的使用體驗和工作效率。

界面精簡，色調冷靜

避免使用艷麗的顏色，影響用戶的心情，干擾用戶的信息識別。盡量使用中性或偏冷的顏色。

類似書法一樣，我們追求 B 端設計能夠在法度中見細節見功夫。

△ 在法度中見細節見功夫

4. 挑戰4，設計方法的挑戰

解決了以上的問題，就進入了具體設計的步驟。但是對 B 端產品來說，C 端交互的設計流程不能簡單地套用。

從用戶的使用場景上看，C 端產品用戶使用產品隨時隨地，用戶關心的是用戶自己，解決的是自己的痛點，而不是進行協作。

從設計師進行設計的角度，C 端產品的設計有一個發散的過程，交互設計師可以使用頭腦風暴的方式，尋找一些相對有突破的交互解決方案，增加一些有趣的功能點，以交互設計師的身份來驅動和豐富產品的設計。但在 B 端交互的起始階段就開始發散是比較危險的，因為對業務不十分熟悉，用戶反饋也相對缺乏，對產品的理解也不深入，因此不建議過早地驅動產品的設計。

總結來說，B 端產品設計，不要著急進行設計發散，首先要合理的功能劃分，這類似于 B 端產品的橫梁與立柱。在具備了比較好的功能模塊劃分和導航邏輯的情況下，根據產品的需求，開發人員的建議，按照設計師整理的思路，在設計標準的約束下，使用統一的控件，以相對比較穩定的模式將交互系統搭建起來。這個過程，比較類似于樂高積木的搭建，或者是樓房的搭建。這些統一的控件就是我們建筑用的磚瓦或者樂高組件。更進一步，我們把一些基本控件組合成更大一些的功能模塊，類似建筑中使用的吊裝模塊，當產品需要這些功能模塊的時候，可以快速地鋪上去。

控件不是憑空編造的，而是通過對業務細節進行學習、思考和設計，考量需要使用的控件和控件組合，之后再反過來豐富控件庫，并制訂好控件庫的套用規則，包括使用的場景，交互的細節等。更進一步，在對業務體系越發熟悉了解的情況下，做到控件使用、定義、組合的融會貫通。

△ 控件和業務的關系

以樂高的方式搭建B端用戶體驗的設計有著顯而易見的好處：

• 一致性得到良好保證；
• 易于協作；
• 易于快速搭建；
• 在需求理解尚不深入且時間有限的情況下，能夠快速提供較為合理的體驗解決方案。

5. 挑戰5，測試方法的挑戰

在可用性測試環節，B 端用戶測試的主要問題在于用戶人數上，C 端業務的用戶數量較大，測試目標用戶容易尋找，但是 B 端產品的有效測試對象并不多，有時非常有限。因此，在 B 端產品的定性測試方面，人員可以貴精不貴多，要盡量深入挖掘服務對象的使用反饋。另外，用建立用戶交流群的方式以及時拿到用戶的反饋，快速響應。

定量研究方面，根據過往的經驗，由于用戶數量不夠，通常很難建立起理想的定量分析模型。舉例來說，表單設計如何用定量數據來分析的模型，雖然可以通過埋點獲得一些有效的數據，但是如何用有限的數據量在較多干擾項的情況下，理清用戶在填寫表單時的行為和操作問題，始終沒能獲得一個令人信服的結果。

由于有效測試用戶和有效數據量的原因，B 端交互的測試要盡量深入挖掘定性研究的結果，為設計和迭代服務。

新的挑戰

功能模塊劃分好了，框架結構建立好了，控件庫做好了，對業務流程的理解越來越深入，此時設計師能夠快速搭建產品的交互，設計效率大幅度提升，原來一周可以做完的工作，現在3、4天可以完成。但是這樣快速搭建的功能，是否就是最優的解決方案呢？

1. 挑戰6，找尋更加優秀的設計方案

技術上來說，新的挑戰存在于交互設計方法本身，由于所有功能模塊全部使用常用控件搭建，限制了一些更有想象力的設計方法，整體上沒有交互方式的突破。積極尋找新的交互方式豐富原有的用戶體驗，就擺在了 B 端交互設計師面前，而設計師也更應該從設計方案的突破上證明自己的價值。

△ 突破樂高──尋找更優秀的設計方案

突破口在哪里？

用戶反映存在問題的功能點往往會成為設計的突破口，實踐證明，在此處尋找新交互方式的成功率比較高，且這種優化方式的成本比較低。

舉例說明：在云服務器的監控設計中，通過對用戶工作場景、操作行為和用戶需求進行分析，了解到用戶在使用性能監控時遇到的問題及建議，由此指導性能監控概覽優化方案的設計。

改版前的性能監控概覽頁面主要存在以下問題：

沒有達到概覽的效果：概覽需要快速了解云服務器的運行全貌，而列表的樣式一頁只能顯示 20~100 個云服務器的監控數據，不能滿足大批量用戶（如某些產品需要上千臺云服務器）概略地了解所有云服務器的監控狀況。盡管列表支持每一列指標排序，但對于整體了解所有云服務器所有指標的情況不是一個最佳的方案。

不能滿足目標用戶的工作場景：一般使用該頁面的目標用戶為運維工程師，他們主要負責產品自身核心業務系統運行情況的監控、問題定位和故障排除等方面的運維工作。所以對于運維工程師來說，快速了解整個產品業務系統的監控狀況和排查相關問題就顯得特別重要，而現有的樣式及交互無法做到快速了解和排查出現的相關問題，從而影響運維工程師的工作效率。

不能體現問題的優先級：當產品出現多個問題時，運維工程師需要判斷出現問題的優先級，及時處理那些問題嚴重、可能影響整個產品正常運行的問題，對于那些問題嚴重程度一般、不會影響整個產品正常運行的問題可以以后處理。而現有的樣式及交互無法整體概覽所有問題，也就更無法區分問題的優先級了。

性能監控改版前的交互樣式為列表呈現方式。如下圖所示：

△ 改版前

改版后的方案介紹：對改版前的問題進行整理及分析，引用了拓撲圖的思維進行相應的方案設計，滿足目標用戶快速了解所有云服務器的監控狀態和快速排查問題的需求，從而提高目標用戶的工作效率。

設計思路：快速定位，局部分析對于大批量的云服務器問題排查，理想的使用場景是先了解所有云服務器的監控情況，然后可以快速定位到出現異常監控指標的云服務器，最后了解具體的異常指標并有針對性地分析可能出現的問題。所以改版的設計思路也是借鑒了快速定位再局部分析的思路，并結合拓撲圖的交互方式進行了設計方案的輸出。

方案介紹：將所有的云服務器都抽象成一個個矩形，按照創建的順序進行 Z 字排列，并顯示在視圖中。矩形的顏色代表云服務器監控指標的狀況。顏色淺表示云服務器的監控指標狀況正常；顏色較深的方框則表示云服務器的某個或多個監控指標相對偏高，但也屬于正常狀態，只是可以引起一定注意；當方塊顏色顯示為黃色，則表示該云服務器內有監控指標出現了異常，這個時候目標用戶就需要引起重視。

△ 改版后 （鼠標hover異常監控顯示詳細信息）

當出現異常的監控指標時，目標用戶可以鼠標 Hover 顯示詳細的監控詳情，也可以放大視圖直觀地了解該云服務器下所有指標的監控狀態和異常指標。

△ 改版后 （拖動鼠標或者點擊縮放按鈕放大視圖）

2. 挑戰7，一致性的再認識

樂高式的工作方法，因為其本身的局限，對控件的定義和一致性方面的要求是比較高的，但這也是這種方法的局限性所在。在把握這些控件的時候，要有一定的彈性，當用戶反復抱怨某處的用戶體驗與一致性有矛盾時，一定要當機立斷，突破一致性的限制。做到設計真正為用戶體驗服務，而不是拘泥于形式。

關于行為的一致性

一個非常典型的例子是云服務器的設置修改。云服務器改版前，云服務器的設置修改，使用的是與創建相同的頁面，不同的僅僅是修改時表單內有默認的值，用戶可以對想要修改的項進行修改，整個云計算平臺的修改設置的做法也完全相同。隨著云服務器創建過程越來越復雜，步驟也逐漸增多，在修改單一設置項的時候，如果還需要打開整個設置頁面，甚至要進行步驟的翻頁，就會造較大的用戶操作負擔。所以在升級版的云服務器操作中，我們逐步將修改設置的用戶行為拆解開，通過一些較輕的操作來解決修改設置的問題。

△ 改版前

△ 改版后

如果僅僅考慮平臺的一致性，遵循現有規范的話，是不應該對頁面進行修改設置的拆解的，而是應該按照打開完整設置頁面進行修改，但是這樣帶來的用戶體驗的負擔是顯而易見的。因此我們在不同的模塊采取了不同的處理辦法。而不是機械地強調一致性。

關于控件的升級

控件是保證一致性的基礎。但是隨著業務的不斷深入，一些控件已經不能非常好地適應業務的發展。因此要對控件進行升級。

檢查控件的適配，有些組合控件因為橫向展示需求較寬，為了適配屏幕尺寸而限制了每個項中具體信息顯示的完整性，此時，可以適當地突破一下適配尺寸的限制。有些控件在使用的規范上可以適當放開，比如下拉菜單的默認狀態，可以是「all」，也可以是「請選擇」，或者是某個默認的值，都可以根據實際情況來制定，不必全平臺統一成一個單一的默認選項。還有一些組合的控件，可以根據用戶需求進行優化升級，比如多選刪除的操作，由于列表顯示撐滿了屏幕，在列表上方或下方放置刪除等功能經常需要用戶大幅度拖拽，妨礙了用戶快速操作，此時可以把操作做成一個彈出的浮層，多選時觸發，既不多占顯示空間，在需要時又可以快速顯示，方便了操作。

3. 挑戰8，深挖不同角色的需求

前面說到，由于 B 端產品存在不同的角色，在提供設計方案的時候要做到兼顧。盡量提供不同角色都可以使用的解決方案。

但是由于知識背景的不同，專家用戶和普通用戶的需求往往是存在一定的差異的。我們在提供一些普通方法的同時，也要深挖用戶需求，同時提供一些專家用戶用起來方便的解決方案。比如以下的案例：

以大數據中創建離線表為例，用戶創建時，我們不僅提供了手工選擇配置項生成新建表的表單模式，也提供了輸入代碼生成新建表的辦法。實際上，輸入代碼創建這種對普通使用者看起來難度超高的辦法，對專家用戶來說，卻是簡單而方便的。因此，使用專家用戶熟悉的方式，極大提高了這部分用戶的使用效率和使用粘性。

△ 手工選擇配置生成新建表

△ 輸入SQL語句生成新建表

3. 挑戰9，平臺同步和問題排除

交互設計是一件既需要宏觀把握，同時也強調細心謹慎的工作。B 端產品，往往十分龐大，功能模塊之間聯系緊密，類似云計算這種平臺，功能眾多，平臺依賴復雜，不同的云形態各異，在每一次功能設計結束之后，往往需要對平臺依賴進行更新，對各種云形態進行配置，這個過程比較繁瑣細碎，如何避免出現問題呢？要建立起常態化的走查工具。

平臺依賴表

上線一個功能，往往會牽扯很多平臺模塊，不能每次牽扯到一處平臺依賴，處理一處平臺依賴。因此要做好 B 端產品的平臺依賴走查工具，在交互文檔提交時確保不會出現遺漏的現象。

△ 平臺依賴表（部分）

錯誤排查表

注意總結經常出現的問題，可能是一些不常見的狀態，可能是一些限制，也可能是一些控件的用法。舉例說，常見的有「資源或流程未創建時的空態是否已經定義，搜索無結果時顯示什么反饋，創建有無配額，配置是否已經達到上限」等。

在交互文檔正式提交前進行一次全面的走查，避免出現類似的常見錯誤。

產品分支形態差異表

由于客戶需求的個性化，底層邏輯的復雜性，B 端平臺可能會有很多不同的形態或分支，要在清晰了解不同形態或分支需求的情況下，先做好基礎形態的交互文檔，并維護好不同分支與不同形態的平臺差異表。

啟發式評估

啟發式評估最先由 Jakob Nielsen 提出，主要是讓 3-5 位可用性專家來評估界面設計是否符合公認的可用性準則（比如著名的Nielsen可用性十原則），以及存在的可用性問題。是能夠快速有效地發現，整理并分析產品中存在的可用性問題，提出設計優化改進建議的過程。這種方法的優點在于成本低，效率高，能在較短的時間內發現很多可用性問題。為了保證平臺的設計質量，可以使用啟發式評估工具，定期對整個平臺設計進行梳理。

如果人力允許，可以對設計進行多人的啟發式評估。當然，現狀往往是設計師之間的交叉評估。無論是多人的評估還是交叉評估，都要保證的是評估人員的獨立性，評估階段不要討論，互相影響，當評估結束之后，再拿出問題進行商討。在報告中應該包括可用性問題的描述，問題的嚴重度，改進的建議等。

評估發現的可用性問題可以根據嚴重程度分為三個優先級，可以根據以下的評估進行評級：

• 問題出現的頻率：在操作中頻繁發生還是很少出現？
• 問題發生時的影響力：用戶是否容易克服？
• 多次操作后，問題的持久度：是一次性出現的問題，還是經常重復影響用戶操作的問題？

根據評估的問題描述和嚴重程度的等級，制定出的任務列表，可以方便我們盡量優先去修改那些問題嚴重性高但需要人力投入比較少的可用性問題。

△ Nielsen可用性十原則

通過以上的工具，設計人員可以有步驟、按計劃、成體系地完善功能和平臺的設計，可以盡量多地避免設計中產生的問題，為項目更好地服務。

總結

通過以上的論述，我們可以把 B 端交互的樂高設計法進行一個總結。樂高設計法可以分成三個重要步驟。

第一步：通過常規流程，確認需求，細分角色，進行合理的模塊劃分后，使用平臺積累創建和定義的統一控件進行功能搭建。

第二步：尋找更優化的交互解決方案，通過深挖用戶對象的差異化需求以及對控件的不斷優化和對一致性的再認識，在解決方案上進行優化突破。

第三步：使用各種工具，完善平臺，排除錯誤，交付優秀的交互文檔和解決方案。

通過以上三個步驟，可以比較好地規范設計流程，有效地產出符合業務需求的設計。同時我們也希望，在實踐中，這個流程仍能夠繼續提升，以適合更多類型的交互設計。

參考文章：

• 把toB產品當成樂高城堡去設計 Jason Wang
• 破繭成蝶 用戶體驗設計師的成長 劉津 李月

歡迎關注「網易UEDC」公眾號：