To B 產品交互的經驗分享——以某云計算平臺為例－楊家山的部落格

編輯導讀：在To C 行業一片飄紅的情況下，To B 行業無疑是近幾年的“香饃饃”，市場潛力大，不少巨頭都投身于此。本文作者作為一個在To B 行業摸爬滾打四年的產品人，對To B 產品交互有著自己的看法。本文以某云計算平臺為例，對其交互體驗進行分析，希望對你有幫助。

之前做ToＢ產品已經快4年了，現在已經從事ToG類產品了，本文總結了個人在ToB產品交互設計中的一些感想與經驗，希望可以對初入ToB產品的交互設計師有一定的幫助。

之前實習的時候做過一些ToC的產品交互設計，后來轉入到做ToB的產品交互設計一直到現在，從ToC到ToB，其實還是有一些很大的區別，其中最大的區別就是對業務以及業務邏輯的理解和交互設計兩方面。下面將具體的說明這兩方面的區別：業務及業務邏輯理解、交互設計。

一、業務及業務邏輯理解

1.1 業務理解

對于交互設計師來說，ToB產品對業務理解能力的要求要高于ToC產品，之所以會這樣是因為兩方面的原因：To B 產品的專業性、個人教育與職業背景。

我們都知道ToC產品的目標用戶是大眾用戶，而ToC產品的需求也當然來源于真實的生活，這樣一來我們理解ToC的業務自然就像是看我們生活的回放一樣。如化妝、訂餐、乘車等都是我們日常生活的一部分，在這些場景下誕生的APP就算不用過多的解釋，我們也能大致了解是干嘛用的，甚至還能出現一些具體場景。而ToB產品的目標用戶往往是一群具有特殊職業的用戶，往往還需要經過特殊學習和培訓才能任職，如程序員、警察、醫生等，我們除了大致了解這些用戶是做什么的之外，對于他們具體的工作卻生疏的狠。

To B 產品需求比 To C 產品需求較難想象具體場景

另外對于交互設計師本身來說，大部分是從工業設計、心理學、計算機等學科出生，并非一個無所不知的人。對于 To C 產品來說我們可能也是其中的一個目標用戶，但是對于 To B 產品來說，我們可能就是一個小白用戶，所以對于一個不熟悉甚至還需要一定的學習才能理解的產品需求，在進行交互設計之前，需要花上一定的時間對目標用戶和具體業務進行了解和分析。

1.2 業務邏輯

在業務邏輯上，To B 產品比 To C 產品業務邏輯相對較為復雜多，主要體現在 To B 產品內模塊之間的依賴性、任務流程的復雜性以及權限分控三個方面。

To B 產品內模塊之間的依賴性相對 To C 產品較強。對于 To B 產品來說，完成一個任務往往依賴幾個模塊配合使用才可正常運行，比如一個用戶使用云計算產品進行網站建設，其至少需要通過云服務器、彈性公網 IP、域名系統、備案系統四個模塊再加上一些配置才能成功搭建一個網站，缺少一塊就無法順利完成網站搭建。而 To C 產品間的依賴相對比較獨立，在進行任務的操作時不會彼此依賴，就拿微信來說通訊、朋友圈、支付相關操作都可以單獨完成，甚至可以獨立成3個產品。

購買云服務器的流程比微信聊天功能的流程長且操作復雜

相對 To C 產品來說，權限分控功能是 To B 產品所獨有的重要功能。To B 產品往往是一個團隊協作的平臺，而對于團隊來說，每個人的職責和權力是不一樣的，這樣就得讓產品根據不同用戶身份角色與權限對用戶的操作進行限制。那某云計算產品來說，團隊里的一部分人負責云服務器，一部分人負責數據庫，一部分人負責創建實例訂單，一部分人負責支付訂單等，各自負責自己的職責。

某云計算團隊不同用戶的不同權限

相對 To C 產品來說，權限分控功能是 To B 產品所獨有的重要功能。To B 產品往往是一個團隊協作的平臺，而對于團隊來說，每個人的職責和權力是不一樣的，這樣就得讓產品根據不同用戶身份角色與權限對用戶的操作進行限制。如某云計算產品來說，團隊里的一部分人負責云服務器，一部分人負責數據庫，一部分人負責創建實例訂單，一部分人負責支付訂單等，各自負責自己的職責，每個職位有每個職位的權利和責任。

二、交互設計

了解了 To B 產品的業務理解和業務邏輯方面與 To C 產品的區別后，我們大致對 To B 產品有一定的了解，那在具體的設計方面是否和 To C 產品一樣呢？還是有著較大的區別？下面將具體的闡述個人對 To B 產品在交互設計上的理解和感悟。

首先不管是ToB還是ToC，在設計宗旨方面兩者應該是具有一致性的，都是針對目標用戶在具體場景下的需求分析，以用戶需求導向為中心來提高用戶體驗的設計，正所謂凡是脫離用戶和場景的交互設計師分析出的一定是個偽需求。但是由于兩者目標用戶和使用場景存在較大的差異性，導致在具體的設計過程中擁有較大的區別，具體將從3個方面來表達 To B 產品的差異性：需求分析、設計思維。

2.1 需求分析

需求分析主要分為用戶需求分析和業務需求分析。

用戶需求簡單的理解就是目標用戶在某一場景下完成特定行為從而達到具體的用戶體驗目標，如在某云平臺創建云服務器實例需求，就可以理解為熟悉云計算的程序員通過某云平臺點擊創建按鈕等操作來快速、順利的完成創建表單的過程。所以目標用戶和使用場景對于用戶需求來說是核心，由于ToB產品目標用戶相比ToC產品目標用戶業務性強且用戶基數少，通常運用在ToC產品用戶需求研究的問卷法等定量分析的方法就不適用于ToB產品，對于ToB產品更適用于用戶訪談和觀察法等定性的研究方法。通過對用戶訪談數據和觀察用戶使用產品場景的分析，構建出目標用戶的用戶角色更直觀方便的幫助理解業務需求。

業務需求也可以簡單的理解為通過什么完成任務來達到什么業務目標，如某一云服務器推廣活動的業務需求，簡單理解就是讓更多用戶創建云服務器來提高云服務器的銷售額。業務需求分析的重點就是如何將業務目標轉化為用戶行為，這又回到對目標用戶在使用產品動機、擔憂以及障礙的分析。所以在需求分析方面，不管是用戶需求分析還是業務需求分析方面，都需要對目標用戶和使用場景進行深入的分析，避免出現“我以為”“我認為”的設計。

2.2 設計思維

由于ToB產品和ToC產品存在的業務邏輯、目標用戶以及體驗目的的差異性，導致ToB產品在具體交互設計時擁有不一樣的設計思維，具體體現在以下四個方面。

2.2.1 先整體后局部

由于ToＢ產品的業務模塊間依賴較大，往往一個功能會涉及到很多地方，這就得要求設計師在進行交互設計時，首先考慮當前需求在整個平臺內涉及的模塊和功能，避免出現功能遺漏。把改需求影響的頁面及功能全部都考慮到后，再考慮當前需求在具體模塊內或功能上的形態和具體交互，以適配不同模塊或功能的差異性。如某云計算平臺創建報警聯系組需求，在報警聯系組模塊使用頁面的形式完成報警聯系組的創建，由報警組名稱、備注和選擇聯系人三項組成。而在創建報警頁面，由于該需求屬于報警規則創建的一項，其呈現方式也為普通的表單項且省略創建聯系組的非必填項備注信息。

創建報警聯系組需求

2.2.2 邏輯嚴謹

由于B端產品的業務復雜性，在進行交互邏輯的設計時應該更加嚴謹，盡可能的考慮全所有操作的可能性與限制，頁面與具體功能對于不同角色用戶的呈現方式等，避免出現因考慮不周上線后出現各種Bug的情況，尤其是ToB產品涉及到計費相關模塊比較多，就更加謹慎。如某個模塊的創建實例按鈕不可點擊的狀態出現的原因就有好幾種，沒有配額、欠費、沒有實名認證、沒有權限等，當這些條件同時存在時又應該優先顯示什么提示。

創建按鈕的不同狀態

2.2.3 效率至上

效率至上也是B端產品與C端產品的一個較大區別，C端產品在滿足用戶需求后側重于滿足用戶情感方面，如怎樣提高用戶粘度、怎樣在使用時提高用戶的情感體驗等方面。B端產品在滿足用戶需求后更側重于提高用戶的工作效率方面，如怎樣更快的完成當前的任務、在頁面信息較多情況下如何讓用戶理解每一個信息等。所以在進行B端產品設計時，遵循效率至上的設計才能提高用戶的滿意度。如進行表單填寫在某個輸入框輸入關鍵字就能顯示一些模糊匹配項進行參考，當Hover到某個語義模糊的圖標按鈕時，會顯示對應的介紹等都是為了提高用戶的工作效率。

2.2.4 簡約通俗

由于ToB產品目標用戶具有特定的工作場景和專業知識，所以在進行設計時所用的語言和一些使用習慣應該盡可能的與目標用戶的真實環境保持一致。這樣用戶在使用產品時會減少對產品的學習成本，提高用戶的使用體驗和工作效率。如某云計算平臺在進行某策略編輯時，將其編輯輸入框設計的與用戶實際工作運用的工具相似，讓用戶更加熟悉、便捷的進行策略編輯。