高手來了！10個B端設計的常見問題答案

本文總結了10個常見的B端設計問題，幫你對B端設計的認識更進一層。

1. 如何具體地理解設計體系和設計規范這兩個概念呢？

“設計規范”更專注于內容上的規則準繩，幫助設計師產出一致的設計方案，傳遞統一的品牌特性。

但實際上，就算團隊中有了一套統一的標準工具和設計指南，部分設計師依然會有新的不一致的“創意”，而前端對應的組件代碼也需要在不同業務中根據設計“創意”而人肉修改。

此外隨著業務迭代，設計師們會更多地面臨“周期性業務的品牌更新”，“不同品牌的多種垂直業務同期構建”，“眾多相似的后臺系統構建”，“跨業務/部門的設計、前端協作問題”。

面對這些問題，體驗工程的建設已經遠遠不止于一套設計規范或一套組件庫，他需要一套完整的系統來支撐，解決內部協作的一致性問題，解決設計系統更新的周期性問題，解決一群設計師與工程師如何規模化的生產各種業務 UI 的問題，從而最終解決用戶體驗一致性的問題。這便需要建設一套“設計體系”。

總結一下二者的區別就是：「設計規范」專注于內容，是公司/業務的設計約束準繩，提供了一套標準來實現體驗一致性，傳遞品牌理念。在目標上更側重于“品牌統一”，內容屬性強于工具屬性。「設計體系」是一個完整的產品，它不僅包含“原則、規范、指南”這些內容，還包含著一系列的協同工具，幫助規模化生產，減少設計和開發的重復工作量。在目標上更側重于“協同提效”，工具屬性強于內容屬性。

2. 產品經理和交互設計師最大的工作內容區別在于？

產品經理

通常更關注產品戰略、產品競爭力、需求洞察和分析、公司商業回報等問題所以他的視角必然是從外到內，市場上有什么變化，競爭對手有什么品牌，目標用戶有什么需求，我們做這事為什么不能賺錢……

為了達到這個目的，他必然要更多地和老板打交道，要和上下游的合作伙伴談判，要爭取內外部的資源 支持，要寫 PRD 和 MRD，要考慮發布會……

你可以理解一個產品的產品負責人，通常就是這個產品的“CEO”。

產品是需要頂層設計思維：

否則為啥還需要產品經理（以下簡稱 PM）？哪怕 PM 只負責一個很小的模塊。如果只是因為頭銜的通貨膨脹，那為啥沒有代碼經理。經理這個 title，說明這個崗位是需要有大局觀的。如果說一個公司對 PM 的定位就是畫一個原型出來，那這個公司基本肯定就是外包公司。

在這里，談一下個人對 PM 的理解。PM 是一個從無到有，從 0 到 1 的創造性崗位。沒有人知道一個產品有哪些功能，長成什么樣才是最好的，沒有標準答案。那難道我們就無法評價一個產品經理工作的好壞了嗎？當然不是。這里就要提到一個心中 PM 的核心技能，商業化。商業化能力對 To B 產品經理是尤其重要的，甚至是最核心的技能，同時也是可以某種程度上評判一個 PM 工作好壞的直觀參考。當我們在考慮是否要做一個產品或者新加一個功能的時候，PM 首要職責是要思考這個產品或者功能

1. 可以解決客戶多大的問題，價值在哪里。
2. 競品有沒有，他們為什么做了，或者為什么沒做。
3. 技術實現的路徑是什么，能做到什么程度。

對這三個問題的思考，合格的 PM 對于一個產品的商業化變現能力有了初步判斷。最怕是客戶要什么就做什么，二怕競品有什么我們就抄什么，這兩種都極不可取。這三個問題思考不到位，很可能后面的努力都變成徒勞。而往往大多數產品的失敗，核心原因也不是產品交互多差，界面多土，而是在一開始就走錯了路。頂層設計就是在我們深入思考后，對于產品的規劃，目標的客戶，推廣的節奏等給出具體的方案。

而商業化能力，不僅僅適用 PM，越是產品的負責人（無論是否是 PM）越應該錘煉自己的商業化能力。

交互設計師

更關注人機交互關系、場景、角色、用戶畫像、交互范式各種專業性問題，所以他的視角經常是從高到低，用戶用我們產品有什么問題，怎么確定哪些問題是重要的，可用性是否出現問題，易用性怎么提升，硬件和軟件能力怎么更好地服務于用戶……

這樣的思考方式促使交互設計師更多地關注產品本身技術平臺、各種競品的差距、用戶感受、交互條件的限制與優化，所以輸出競品分析報告、場景分析、任務流程圖、交互模塊邏輯關系圖、用戶研究、紙面原型、高保真原型 demo……

你可以理解一個產品的交互設計師是這個產品在 UX 框架層面的專家，他決定你的業務邏輯怎么解釋為用戶邏輯，而不是技術邏輯。現在 B 端都沒有純視覺 UI，都是和交互合并成產品體驗設計師。上接用戶、產品和業務，下接開發和測試。有人說交互設計師是“設計 PM”，還挺貼切的~

3. 組件搭建之后，產品經理直接拿組件去拼頁面，直接進入開發

那么設計的價值在哪？另外公司不重視設計和組件，我們應該怎么辦？

第一：關于搭建組件之后，產品直接拖拽使用，設計怎么辦，價值在哪？

個人認為其實非常好，證明你的搭建工作發揮了價值，提高了整個產研部門的效率。你在這個過程中可以逐漸從不必要、重復性設計事務中解放出來，有時間去關注整體的產品交互，以及產品流程的合理性，以及如何從產品層面去優化整體產品體驗等等。才能體現 tob 產品設計師的價值，才不會被別人稱作是拖拽組件的“工具人”。

第二：目前公司不重視設計和組件化怎么辦呢？

這個我建議把眼光放的長遠一些，我們和公司只是合作關系，我們的個人成長不管是從技能上還是從認知上，收益最大的永遠是個人。沒有幾個人會一直待在一個公司，但是隨著你的能力的提升，你會遇到更好的公司，也會有更多選擇，夢想總是要有的。

4. B 端組件的搭建在具體的作品集中的占比應該多少？會加分么？

首先作為 B 端設計擁有組件化思維和組件化構建能力是必須的。但是具體是否需要在作品集展示，展示多少，能加多少分，需要去結合自身的階段去看。比如你是一個初級設計師，那么你至少會設計使用組件，知道組件的原理，以完成日常的設計工作；如果是中級設計或者是高級設計則需要減少組件設計的部分。尤其是如果你申請的是一個管理崗位，我們固然不需要用很大的篇幅去討論怎么做組件，而是要把重點放到把控設計任務的質量和時間等等。

5. 組件搭建的范圍是？什么內容需要做成組件，選擇的依據是？

組件搭建范圍：

頁面底層的框架，原子層的柵格、間距、字體、顏色、陰影等的具體定義、使用范圍、為什么要這么定義。底層框架的原理決定著頁面的秩序和前端實現的成本。依次向上到基礎組件、業務組件、區塊組件，最終基于組件多嵌套組合成場景頁；

組件化內容的選擇依據：

對于 B 端的產品來說，在結構細分時，項目中滿足復用性和拓展性的可拆解的模塊均可以組件化；把頁面窮舉羅列出來，分析相似性和可替換的模塊，然后利用思維導圖的方式羅列出可組件化的內容，做成可替換的組件，使每個原子可獨立變化和替換，這種多嵌套組合式的細分方式，讓組件最終呈現出來的樣式滿足多場景的業務需求。

6. 什么時候是做組件庫的時機？

在 B 端產品中，做組件庫的時機要需要產品發展到較為穩定的版本，這個階段公司把整體把系統性提升產品體驗和服務的競爭優勢提上了日程；畢竟 B 端的組件庫需要結合業務設計出符合業務場景的樣式?，真正可以組件化的邏輯和樣式是不可以憑空想象的，需要積累足夠的了解業務邏輯，足夠的業務場景。

總結

1. 產品發展到較為穩定的版本
2. 設計師足夠的了解業務邏輯
3. 積累足夠的業務場景
4. 產品線多、項目多、設計師多、工程師多；
5. 公司所處階段重視產品體驗、品牌化、差異性；

7. 想問一下你了解的 B 端企業工作流程是什么樣的？各個流程設計師需要完成哪些內容？

B 端企業工作流程：

我所了解到的企業工作流，是當客戶有意向的時候，對應的客戶經理（產品經理）會針對具體的需求輸出原始的用戶需求文檔書，并給出簡單的原型設計先和客戶確認，確定立項之后，會拉著各個業務線的 leader 一起對原型評審。到這個時候最重要的就是設計部門的意見，因為一旦原型被拍板通過，后續如果在出現產品功能需求上的問題會把鍋扣在設計頭上。所以一般在這個階段我們都會比較謹慎，所有問題基本都會暴露出來。當然我理解把問題前置是一個好的事情。設計完成高保真之后，在開發之前還會進行高保真 Review，參與的人員和評審原型時一致。如果高保真評審通過就會進入到開發測試階段，上線之前設計部門會進行還原度驗收，形成設計驗收報告，并告知客戶經理和開發經理，最終上線效果會根據具體的項目要求和時間來定；

8. toB 和 toG 的區別除了目標定位外，你認為具體還有哪些區別？

一般政府以及官方機構被稱為 G 端，嚴格來說 G 端屬于 B 端的一種。所以 B 端的共性就是為了提高企業運行效率。那么我會重點說一下我接觸到的一些明顯區別。

G 端包括實體的智能硬件以及軟件服務或者解決方案

智能硬件又包括智慧園區中的無人汽車，X 廠的智能裝貨機器人，以及很多實際應用的智能硬件。其實目前很多 G 端的企業在發硬件發展上是很快的，我在沒真實參觀之前也沒有想到，一個 X 廠居然可以完全不用人，就可以實現全自動化生產。這里面當然包括很多軟件硬件的解決方案共同協同。

還有一點就是 G 端更著重強調預警：

不管是我們日常看到的街道違規抓拍，以及工廠里面設備故障，等等其實主要功能側更側重于強調預警。在違章或者故障發生之后第一時間通知對應的人去處理。隨著科技慢慢的發展，人工智能 AI 的介入，以及各種算法和大量數據的采集，以后的預警可能真的會在故障或者事故發生之前，就做出預警的動作，從而避免真正警情的發生。

9. 現在組件都這么成熟了，為什么還要自己花這么大成本去搭建呢？

其實這是跟你的公司的戰略方向、發展階段相關的。對于一個中小型企業或者他可能就覺得用現有的開源組件，已經是夠用并且好用，我為什么還要去自己做呢？沒毛病，這種情況下還是以目的導向的，你想節約成本，就去用別人就成熟的這種規范去搭就 ok 了，沒問題的。

但是有另外的情況就是：一：開源的組件庫、場景庫（pro）基礎，無法滿足企業內特殊復雜的業務場景；二：公司發展到一定程度了，想要品牌化、差異性化；自然會自上而下的去要求和推動產品體驗升級和組件化的進程；

10. B 端設計師如何快速理解業務？

查閱行業報告

如果是之前從未接觸的新業務，我們可以通過市面上的行業報告，來對該行業有個大體的認知，因為在行業報告中，會提到行業的發展狀態，政策導向以及未來的發展趨勢。

理解產品專有名詞

專業業詞匯對于 B 端設計師理解上是有難度的，在實際工作溝通當中都需要通過專業詞匯來進行準確的描述。比如在 OCR 產品當中,我們必須要了解：分類器、K-V、自定義模版/模型、參照字段等一些專有名詞詞匯，而詞匯的背后往往是產品當中的深層邏輯。理解專有名詞的含義然后逐步再去理解流程和業務邏輯；我們可以選擇直接競對通過競品的官網、產品試用等，我們可以尋找到"用戶手冊、幫助中心”等模塊，也可以去看自家產品沉淀的產品說明書，里面就會有相應的專業詞匯的講解；從而加深對產品的理解；

競品體驗試用

試用往往是在真實的環境下對該產品進行體驗，試用可能是銷售人員給到你相應的體驗測試賬號，或者你可以直接注冊。設計師應該根據競品的官網或銷售人員演示的流程或產品文檔進行相應的頁面梳理,通過截圖將該產品的主流程進行截圖。最終將頁面流程靜態的還原到設計圖上，一是遇到同類型需求時,能夠快速了解競品的功能設計思路；二是幫助我們在產品的后續更新迭代，有了可以參考的版本。如果無法拿到直接競品的體驗賬號，我們也可以去體驗相關聯競品；

產品體驗走查，理清流程和結構

對照產品白皮書體驗自身產品，體驗過程中列出主功能流程圖以及對比分析流程和內容合理性，將問題和疑惑記錄下來和產品經理進行溝通，深刻理解業務，對癥下藥才能提供出切實可行且合理的設計方案；

歡迎關注作者微信公眾號：「IM UED」