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

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

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

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

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

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

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

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

同理心挑戰(zhàn)

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

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

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

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

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

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

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

??

象限分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

角色分析

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

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

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

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

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

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

問題三：?jiǎn)渭優(yōu)橛脩舳O(shè)計(jì)

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

挑戰(zhàn)3：設(shè)計(jì)標(biāo)準(zhǔn)的挑戰(zhàn)

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

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

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

（1）功能清晰， 模塊劃分準(zhǔn)確

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

（2）交互流程精準(zhǔn)切合業(yè)務(wù)實(shí)際場(chǎng)景

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

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

使用相同的控件， 保持體驗(yàn)的一致性。

（4）用戶理解簡(jiǎn)約通俗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、新的挑戰(zhàn)

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

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

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

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

突破口在哪里？

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

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

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

（1）沒有達(dá)到概覽的效果

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

（2）不能滿足目標(biāo)用戶的工作場(chǎng)景

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

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

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

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

改版前

改版后的方案介紹：

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

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

方案介紹：

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

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

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

改版后 （拖動(dòng)鼠標(biāo)或者點(diǎn)擊縮放按鈕放大視圖）

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

樂高式的工作方法， 因?yàn)槠浔旧淼木窒蓿?對(duì)控件的定義和一致性方面的要求是比較高的。但這也是這種方法的局限性所在。在把握這些控件的時(shí)候， 要有一定的彈性，當(dāng)用戶反復(fù)抱怨某處的用戶體驗(yàn)而與一致性有矛盾時(shí)， 一定要當(dāng)機(jī)立斷， 突破一致性的限制。做到設(shè)計(jì)真正為用戶體驗(yàn)服務(wù)，而不是拘泥于形式。

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

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

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

改版前

改版后

如果僅僅考慮平臺(tái)的一致性 ，遵循現(xiàn)有規(guī)范的話，是不應(yīng)該對(duì)頁(yè)面進(jìn)行修改設(shè)置的拆解的，而是應(yīng)該按照打開完整設(shè)置頁(yè)面進(jìn)行修改， 但是這樣帶來的用戶體驗(yàn)的負(fù)擔(dān)是顯而易見的。因此我們?cè)诓煌哪K采取了不同的處理辦法。而不是機(jī)械地強(qiáng)調(diào)一致性。

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

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

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

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

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

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

但是由于知識(shí)背景的不同， 專家用戶和普通用戶的需求往往是存在一定的差異的。我們?cè)谔峁┮恍┢胀ǚ椒ǖ耐瑫r(shí)， 也要深挖用戶需求， 同時(shí)提供一些專家用戶用起來方便的解決方案。比如以下的案例：

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

手工選擇配置生成新建表

輸入SQL語句生成新建表

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

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

（1）平臺(tái)依賴表

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

平臺(tái)依賴表（部分）

（2）錯(cuò)誤排查表

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

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

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

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

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

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

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

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

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

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

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

Nielsen可用性十原則

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

總結(jié)

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

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

樂高設(shè)計(jì)法

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

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

參考文章：

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

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

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

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