面對突如其來的B端體驗設(shè)計的挑戰(zhàn)， 設(shè)計師該如何應(yīng)對？或者說設(shè)計師的思路該如何針對B端設(shè)計的特點進行調(diào)整？甚至設(shè)計管理的思路如何調(diào)整？一起來文章中看看解決辦法~

隨著互聯(lián)網(wǎng)常規(guī)C端業(yè)務(wù)逐漸由藍海轉(zhuǎn)為紅海， 易變現(xiàn)的業(yè)務(wù)類型漸趨穩(wěn)定， 一方面C端互聯(lián)網(wǎng)業(yè)務(wù)本身快速更迭淘汰， 而另一方面業(yè)務(wù)的深度和市場需求的發(fā)掘漸趨緩慢，在此趨勢下， 互聯(lián)網(wǎng)從業(yè)者努力地尋找C端業(yè)務(wù)新的增長點。與此同時，各大廠紛紛部署B(yǎng)端業(yè)務(wù)， 而B端用戶體驗設(shè)計因其業(yè)務(wù)尚是一片藍海， 且由于自身的特點， 所以具有較高的業(yè)務(wù)門檻和業(yè)務(wù)深度的持續(xù)可挖掘性。

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

一、來自B端設(shè)計的各種挑戰(zhàn)

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

挑戰(zhàn)1：同理心挑戰(zhàn)

C端產(chǎn)品中， 交互設(shè)計師的任務(wù)是發(fā)現(xiàn)用戶需求，定義用戶價值，解決用戶在使用場景中的痛點，并推動項目達成這一目標。

作為交互設(shè)計師， 同理心正是我們發(fā)現(xiàn)用戶需求， 模仿用戶行為， 揣摩用戶意圖， 鎖定用戶目標，解決用戶痛點的法寶， 我們之所以可以這么做， 是因為在C端用戶體驗的設(shè)計中， 交互設(shè)計師大部分情況下都或多或少地就是用戶本身，或者帶有用戶屬性。

同理心挑戰(zhàn)

B端產(chǎn)品， 是根據(jù)客戶的戰(zhàn)略或服務(wù)于線下已有的流程， 構(gòu)建生態(tài)體系， 推動將流程系統(tǒng)化，管理數(shù)據(jù)資產(chǎn)，獲取核心的生產(chǎn)經(jīng)營數(shù)據(jù)， 提高生產(chǎn)經(jīng)營效率，幫助企業(yè)決策。一般情況下， 交互設(shè)計師的B端產(chǎn)品的用戶屬性往往無限趨近于零。

以市場上常見的B端產(chǎn)品為例：

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

市場上常見的B端業(yè)務(wù)

考察以上的業(yè)務(wù)類型， 可以說交互設(shè)計師平時除了在財稅系統(tǒng)和OA系統(tǒng)有一部分報銷或者工作協(xié)同使用需求外， 其他幾乎什么都挨不著邊，更不要說專業(yè)挑戰(zhàn)巨大的醫(yī)療系統(tǒng)和技術(shù)挑戰(zhàn)很大的云計算和大數(shù)據(jù)系統(tǒng)了。

實際工作中，尤其是在剛剛開始從事B端交互設(shè)計的起初一段時期， 越是設(shè)計類出身的交互設(shè)計師， 越是會體會到一種無從下手的感覺， 很大一部分設(shè)計基本思路都是產(chǎn)品和開發(fā)告知的， 因此也難免會產(chǎn)生一種無法對項目產(chǎn)生影響的無力感。

因此， 如果將B端交互業(yè)務(wù)分為幾個象限的話，越是處在右下方的產(chǎn)品， 對大部分交互設(shè)計師的門檻越高。

??

象限分析

要更好地理解B端業(yè)務(wù)，沒有其他的應(yīng)對辦法， 必須認真做好以下兩點：

（1）謙虛踏實地學(xué)習(xí)業(yè)務(wù)

以云計算大數(shù)據(jù)為例， 首先要吃透自己手里的設(shè)計工作的業(yè)務(wù)細節(jié)， 向產(chǎn)品和開發(fā)同事詳細了解產(chǎn)品的需求，弄清每個步驟的業(yè)務(wù)邏輯，甚至開發(fā)的實現(xiàn)模型， 測試對細節(jié)的要求等等…… 在確認需求的環(huán)節(jié)， 當需求方希望你把一些較為難于理解的業(yè)務(wù)設(shè)計成某種他希望的樣式時，一定要將業(yè)務(wù)邏輯理解透徹再考慮應(yīng)該如何進行設(shè)計實現(xiàn)。

要問問為什么業(yè)務(wù)流程是這樣， 為什么用這幾個菜單， 這個填代碼的區(qū)域， 要用戶填的是什么意義的代碼，列表的每一列的含義是什么， 詳情的每個指標說明了什么含義？

自己要清楚知道整個頁面里的每個控件， 控件的每個選項的業(yè)務(wù)含義是什么。要探討流程的業(yè)務(wù)合理性， 越是復(fù)雜有爭議就越要盡量多提供幾套方案以供討論；要斟酌用詞是否清晰和正確， 陳述是否專業(yè)嚴謹又易于理解，盡量少帶語氣等等。

（2）做好用戶調(diào)研工作

積極地與用戶接觸，參與或組織用戶調(diào)研。用戶可以請多名用戶做訪談， 做好訪談腳本， 了解現(xiàn)有設(shè)計有哪些痛點。這些真實的痛點， 往往是產(chǎn)品、架構(gòu)師無法預(yù)料的。

舉例來說， 在云計算業(yè)務(wù)由面向小B用戶到大B用戶的轉(zhuǎn)變過程中， 通過對目標用戶的深入訪談， 了解到現(xiàn)有的云計算產(chǎn)品實現(xiàn)對大B用戶來說，除了存在一些普通的有共性的體驗問題之外， 還存在大量的批量操作問題，批量刪除， 批量啟動， 批量查找， 批量顯示等， 是需求確認和設(shè)計過程中始料未及的。

挑戰(zhàn)2：目標用戶的挑戰(zhàn)

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

實際工作中發(fā)現(xiàn)， B端產(chǎn)品的用戶數(shù)量卻往往比較有限。更重要地， 用戶往往不是客戶， 而是一個組織， 包含三個維度， 包括決策者、管理者和執(zhí)行者。

其中決策者是客戶，而管理者和執(zhí)行者是不同角色的用戶。決策者作為B端產(chǎn)品的客戶，并不一定需要經(jīng)常使用產(chǎn)品， 但決定是否購買產(chǎn)品。因此， 在客戶這個層面，要從企業(yè)管理的層面去理解客戶的需求，考慮產(chǎn)品能否幫助客戶理順管理流程 提高效率，節(jié)約成本，獲得穩(wěn)定安全的資源，提高客戶的購買意愿。

而針對管理者和執(zhí)行者的用戶層面，由于需要滿足不同角色間的生產(chǎn)協(xié)作需求，滿足不同層級和組織內(nèi)外的協(xié)同溝通需求。因此在具體設(shè)計操作層面， 要做好不同層級的用戶畫像， 為不同層級的用戶提供必需的使用權(quán)限， 根據(jù)用戶的分級去做好每一級用戶的體驗設(shè)計。

由于系統(tǒng)的復(fù)雜， 在執(zhí)行者這個層面， 也往往存在很多不同的角色， 不同角色間同樣有不同的需求， 在設(shè)計中要分辨清楚， 協(xié)調(diào)好解決方案。

舉例來說：在大數(shù)據(jù)產(chǎn)品中，數(shù)據(jù)開發(fā)和數(shù)據(jù)分析師，都是大數(shù)據(jù)系統(tǒng)的用戶，但是他們的需求有一定的差異。在搜索表的時候， 數(shù)據(jù)開發(fā)更關(guān)心自己常用的收藏表和項目內(nèi)的公共表， 而數(shù)據(jù)分析師并不關(guān)心固定的表，但是關(guān)心他瀏覽過的表的記錄。

因此， 在提供表搜索的設(shè)計時， 要把這兩個層面的需求同時考慮進去，也就是說如何在同一個頁面，設(shè)計能同時滿足兩種不同的需求，以便數(shù)據(jù)開發(fā)工程師和數(shù)據(jù)分析師都能方便地使用產(chǎn)品。

角色分析

關(guān)于目標用戶的確認， 在具體的實踐中還往往出現(xiàn)以下一些問題，是在設(shè)計分析階段要盡量避免的：

問題一：為自己設(shè)計

一些軟件相關(guān)專業(yè)出身的設(shè)計師相對比較理解一些底層的業(yè)務(wù)邏輯， 但實際上他們并非真正的用戶。這部分設(shè)計師存在自己制定框架制定規(guī)矩， 讓用戶在此框架里玩的想法，但不去理解用戶到底想要什么。

當用戶明確提出體驗問題時，又從實現(xiàn)模型出發(fā)認為設(shè)計就應(yīng)該是那樣的，不愿也不應(yīng)該尋找替代的設(shè)計，導(dǎo)致用戶易用性受到非常嚴重的影響。這種設(shè)計不是以用戶為中心的，而是以設(shè)計師本人為中心的， 極不可取。

問題二：為程序員而設(shè)計

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

問題三：單純?yōu)橛脩舳O(shè)計

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

挑戰(zhàn)3：設(shè)計標準的挑戰(zhàn)

B端交互的產(chǎn)品設(shè)計， 由于有著清晰的目的性， 比如財務(wù)系統(tǒng)類、協(xié)同操作類、云計算大數(shù)據(jù)類、工業(yè)互聯(lián)網(wǎng)類等等B端業(yè)務(wù)的體系， 都有著清晰的操作目的，它們顯然都不是帶著用戶漫無目的地遨游互聯(lián)網(wǎng)，或者消磨時間， 或者滿足虛榮心， 或者發(fā)泄情緒， 或者滿足用戶其他的欲望， 而是有清晰精準的業(yè)務(wù)目標。

因此“效率第一”就成為B端交互設(shè)計的第一標準。追求花里胡哨的用戶界面， 超出主線的附加用戶功能， 過分情感化的體驗設(shè)計， 都不應(yīng)該是B端交互需要遵從的設(shè)計標準。

根據(jù)以往經(jīng)驗的總結(jié)，拆解到具體的B端交互設(shè)計上， 是要求設(shè)計師做到以下幾點：

（1）功能清晰， 模塊劃分準確

功能模塊分類清晰， 用戶一目了然， 減少學(xué)習(xí)成本。

（2）交互流程精準切合業(yè)務(wù)實際場景

各步驟之間銜接自然流暢， 精準切合業(yè)務(wù)實際的流程。

（3）體驗統(tǒng)一而有序

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

（4）用戶理解簡約通俗

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

（5）界面精簡， 色調(diào)冷靜

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

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

在法度中見細節(jié)見功夫

挑戰(zhàn)4：設(shè)計方法的挑戰(zhàn)

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

從用戶的使用場景上看， C端產(chǎn)品用戶使用產(chǎn)品隨時隨地， 用戶關(guān)心的是用戶自己， 解決的是自己的痛點， 而不是進行協(xié)作。

從設(shè)計師進行設(shè)計的角度， C端產(chǎn)品的設(shè)計有一個發(fā)散的過程， 交互設(shè)計師可以通過使用頭腦風(fēng)暴的方式尋找一些相對有突破的交互解決方案，增加一些有趣的功能點 ，以交互設(shè)計師的身份來驅(qū)動和豐富產(chǎn)品的設(shè)計。

但是對交互設(shè)計師來說， 在B端交互的起始階段就開始發(fā)散是比較危險的，因為對業(yè)務(wù)不十分熟悉， 用戶反饋也相對缺乏，對產(chǎn)品的理解也不深入， 因此不建議過早地驅(qū)動產(chǎn)品的設(shè)計。

總結(jié)來說， B端產(chǎn)品設(shè)計，不要著急進行設(shè)計發(fā)散。首先要解決的是合理的功能劃分，這類似于B端產(chǎn)品的橫梁與立柱，在具備了比較好的功能模塊劃分和導(dǎo)航邏輯的情況下，根據(jù)產(chǎn)品的需求， 開發(fā)人員的建議，按照設(shè)計師整理的思路，在設(shè)計標準的約束下，使用統(tǒng)一的控件，以相對比較穩(wěn)定的模式將交互系統(tǒng)搭建起來。

這個過程， 比較類似于樂高積木的搭建， 或者是樓房的搭建，這些統(tǒng)一的控件就是我們建筑用的磚瓦或者樂高組件。更進一步， 我們把一些基本控件組合成更大一些的功能模塊， 類似建筑中使用的吊裝模塊，當產(chǎn)品需要這些功能模塊的時候，可以快速地鋪上去。

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

控件和業(yè)務(wù)的關(guān)系

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

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

挑戰(zhàn)5：測試方法的挑戰(zhàn)

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

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

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

二、新的挑戰(zhàn)

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

挑戰(zhàn)6：找尋更加優(yōu)秀的設(shè)計方案

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

突破樂高——尋找更優(yōu)秀的設(shè)計方案

突破口在哪里？

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

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

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

（1）沒有達到概覽的效果

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

（2）不能滿足目標用戶的工作場景

一般使用該頁面的目標用戶為運維工程師，他們主要負責產(chǎn)品自身核心業(yè)務(wù)系統(tǒng)運行情況的監(jiān)控、問題定位和故障排除等方面的運維工作。所以對于運維工程師來說，快速了解整個產(chǎn)品業(yè)務(wù)系統(tǒng)的監(jiān)控狀況和排查相關(guān)問題就顯得的特別重要，而現(xiàn)有的樣式及交互無法做到快速了解和排查出現(xiàn)的相關(guān)問題，從而影響運維工程師的工作效率。

（3）不能體現(xiàn)問題的優(yōu)先級

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

性能監(jiān)控改版前的交互樣式為列表呈現(xiàn)方式，如下圖所示：

改版前

改版后的方案介紹：

對改版前的問題進行整理及分析，引用了拓撲圖的思維進行相應(yīng)的方案設(shè)計，滿足目標用戶快速了解所有云服務(wù)器的監(jiān)控狀態(tài)和快速排查問題的需求，從而提高目標用戶的工作效率。

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

方案介紹：

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

改版后 （鼠標hover異常監(jiān)控顯示詳細信息）

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

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

挑戰(zhàn)7：一致性的再認識

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

（1）關(guān)于行為的一致性

一個非常典型的例子是云服務(wù)器的設(shè)置修改。云服務(wù)器改版前， 云服務(wù)器的設(shè)置修改， 使用的是與創(chuàng)建相同的頁面， 不同的僅僅是修改時表單內(nèi)有默認的值， 用戶可以對想要修改的項進行修改，整個云計算平臺的修改設(shè)置的做法也完全相同。

隨著云服務(wù)器創(chuàng)建過程越來越復(fù)雜， 步驟也逐漸增多， 在修改單一設(shè)置項的時候，如果還需要打開整個設(shè)置頁面，甚至要進行步驟的翻頁，就會造較大的用戶操作負擔。所以在升級版的云服務(wù)器操作中， 我們逐步將修改設(shè)置的用戶行為拆解開， 通過一些較輕的操作來解決修改設(shè)置的問題。

改版前

改版后

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

（2）關(guān)于控件的升級

控件是保證一致性的基礎(chǔ)。但是隨著業(yè)務(wù)的不斷深入， 一些控件已經(jīng)不能非常好地適應(yīng)業(yè)務(wù)的發(fā)展。因此要對控件進行升級。

檢查控件的適配， 有些組合控件因為橫向展示需求較寬，為了適配屏幕尺寸而限制了每個項中具體信息顯示的完整性， 此時， 可以適當?shù)赝黄埔幌逻m配尺寸的限制。有些控件在使用的規(guī)范上可以適當放開， 比如下拉菜單的默認狀態(tài)， 可以是“all”，也可以是“請選擇”，或者是某個默認的值， 都可以根據(jù)實際情況來制定，不必全平臺統(tǒng)一成一個單一的默認選項。

還有一些組合的控件， 可以根據(jù)用戶需求進行優(yōu)化升級， 比如多選刪除的操作，由于列表顯示撐滿了屏幕， 在列表上方或下方放置刪除等功能經(jīng)常需要用戶大幅度拖拽，妨礙了用戶快速操作。此時可以把操作做成一個彈出的浮層， 多選時觸發(fā)，既不多占顯示空間， 在需要時又可以快速顯示， 很大方便了操作。

挑戰(zhàn)8：深挖不同角色的需求

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

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

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

手工選擇配置生成新建表

輸入SQL語句生成新建表

挑戰(zhàn)9：平臺同步和問題排除

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

（1）平臺依賴表

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

平臺依賴表（部分）

（2）錯誤排查表

注意總結(jié)經(jīng)常出現(xiàn)的問題，可能是一些不常見的狀態(tài)， 可能是一些限制， 也可能是一些控件的用法， 舉例說，常見的有“資源或流程未創(chuàng)建時的空態(tài)是否已經(jīng)定義， 搜索無結(jié)果時顯示什么反饋， 創(chuàng)建有無配額， 配置是否已經(jīng)達到上限”等。

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

（3）產(chǎn)品分支形態(tài)差異表

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

（4）啟發(fā)式評估

啟發(fā)式評估最先由Jakob Nielsen提出，主要是讓3-5位可用性專家來評估界面設(shè)計是否符合公認的可用性準則（比如著名的Nielsen可用性十原則）以及存在的可用性問題。是能夠快速有效地發(fā)現(xiàn)，整理并分析產(chǎn)品中存在的可用性問題，提出設(shè)計優(yōu)化改進建議的過程。

這種方法的優(yōu)點在于成本低，效率高，能在較短的時間內(nèi)發(fā)現(xiàn)很多可用性問題。為了保證平臺的設(shè)計質(zhì)量， 可以使用啟發(fā)式評估工具， 定期對整個平臺設(shè)計進行梳理。

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

評估發(fā)現(xiàn)的可用性問題可以根據(jù)嚴重程度分為三個優(yōu)先級，可以根據(jù)以下的評估進行評級：

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

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

Nielsen可用性十原則

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

總結(jié)

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

• 第一步：通過常規(guī)流程，確認需求，細分角色，進行合理的模塊劃分后， 使用平臺積累創(chuàng)建和定義的統(tǒng)一控件進行功能搭建。
• 第二步：尋找更優(yōu)化的交互解決方案， 通過深挖用戶對象的差異化需求以及對控件的不斷優(yōu)化和對一致性的再認識， 在解決方案上進行優(yōu)化突破。
• 第三步：使用各種工具， 完善平臺，排除錯誤， 交付優(yōu)秀的交互文檔和解決方案。

樂高設(shè)計法

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

以上就是我關(guān)于B端產(chǎn)品交互設(shè)計流程的一些心得，歡迎討論分享

參考文章：

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

作者： 盧小飛，微信公眾號：網(wǎng)易UEDC

本文來源于人人都是產(chǎn)品經(jīng)理合作媒體@網(wǎng)易UEDC，作者@盧小飛

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