編輯導語：放眼當今網際網路趨勢，B端大有可為。那麼作為B端產品設計者，需要在這樣的大環境下保持著不斷學習與勤練自身邏輯思維與總結自己的一套工作方法。作者在文中沉澱其工作3年的經驗，與大家學習交流。

B端產品之路，亦錘鍊之路，求真之路，懷造福家國四方，利他共贏之心，效往聖先賢德行，誠然為事，不矜不伐，則能使商企之間齊驅並進。

近3年的產品工作沉澱，即觀察到如今網際網路的發展趨勢，B端大有可為，遂驅使自己提起筆桿欲同業界同仁分享請教，“高山仰止，景行行止，雖不能至，然心嚮往之”，以下正文。

進入網際網路5G紀元，各行業的技術銜接手段和資訊更新效率越來越快。

作為一名B端產品的設計者，或者說是架構者，產品的分析定位、設計架構、功能和業務環節之間的關聯和打通，不但要保證科學嚴謹的流程和規範，產品設計者還需要依據自身的行業經驗和對產業網際網路、工業自動化、國情政策、企業類服務專案及新型科學技術（如Ai、AR、MR）、社會關係學等多方面的洞察和理解。

再結合當下網際網路的技術發展趨勢，在B端產品設計之中融入獨特且絕對有用的功能設計，專案才可能有脫穎而出的機會。

本文總結近兩年間做B端產品設計的歷練和見聞，也為勤練自身思維的連貫，以及向諸多前輩、同仁們取經求教，整理一篇關於B端產品工作的心得筆記。

一、 B端如何做到合理化輸出解決方案和設計？

B端產品的方案和設計，時刻需要圍繞業務需求展開，合理化意味著並不一定是最好，但一定是最可能被甲方領導認同並透過使用的方案和設計。

在市場審度及同行或團隊眼中，不同行業、不同角度關注的細節各有不同，但重要的是方案和設計的易讀性強（符合大眾審美需求，且容易理解和操控），讚許多於嘲諷則是真成績。

1.對合理化方案輸出的工作方法

（1）清晰理解業務，甚至要比需求方還要懂他們的業務

B端產品設計時刻圍繞業務展開，一個B端專案往往包含很多條業務，每一條業務都會關聯到相關的部門、角色（人）、以及角色的許可權（人的許可權），甚至有些業務會涉及到不同的工作流程，還會分階段完成，以達到最終目的。

所以對於B端產品負責人而言，理清每條業務，熟悉每條業務的環節和可能突發的各種問題，看清需求背後的真正需求是展開專案的根本。

舉例自己曾負責過的一個企業服務類的專案，當時領導要求做一個CRM的專案，大致需求是：

各子公司的部門領導可自建組織架構，向下屬分配合同訂單，且能監控合同工單的執行全過程；

員工可自建合同訂單，上傳執行資料，同步工作進度；

合同工單具備業務計算能力（財稅計算邏輯）；

系統需具備合同訂單過濾篩查及業務分析能力；

系統需具備銷售業績提成計算功能。

在這五條需求中，後兩條其實是我經過了1年多的產品工作之後，至今回憶起這個專案才不充上去，以用來和各位同仁舉例。

其實當時完成這個專案僅是實現了前3個需求，而當時企業面臨的問題如今回憶起來並非是對合同工單的管理難點，多數子公司利用原系統後臺就已經將合同管理得很好，

其真正需求是在於對企業核心業務的業績拔高。

可能對企業服務有較為深刻理解的同仁可以更明白，決定客戶與服務團隊簽訂合同的重要因素有價格、效率及專業保障，對於合規避稅的業務來說，減稅的額度是真金白銀，這對客戶是絕對的吸引，而對企業內部員工來說，籤成一單合同帶來的佣金收益，是他們最想要的。

由於團隊也沒有很好地結合行業狀況和企業內部問題做產品分析評估，最後專案即便落地也沒有實際為企業創造出較好的業務收益，所以看清問題本質，瞭解一線的實際業務情況，對於B端產品設計十分重要，產品負責人應持眼見為實的態度，用產品方案去解決最實際的問題。

（2）該有的流程圖，調研列舉，業務分析報告不能少

上面有提到，B端產品的特性之一是涉及到的人、部門多，細節到儀器、裝置、工廠、環境等各種資料的引數更是不勝列舉。

破除部門、人之間的資訊孤島和壁壘是產品的核心任務，所以在B端產品理論設計階段之初，對業務、工作流及裝置間配合的流程必須要以規範的流程圖做梳理，這也是為了便於後續研發團隊及同甲方的業務對接中，提高效率。

而對於B端專案的調研列舉和業務分析報告，這個要分行業，像一些常規的B端專案，如CRM、ERP、SAAS或部分資料中臺，市面上有很多可供產品負責人去參考調研，也很容易產出一份分析報告，具體方法我會在後續的2、3篇內與同仁們分享具體的方法。

而對於國家級的保密專案，一般很少能有拿到明面上參考的專案，這裡產品負責人可以向業內專家請教或尋找一些國外資源作為參照，以此作為前期專案彙報的論證。

（3）原型是最直接的說服工具，也是方案助推工具

B端使用者在視覺層面和對功能操控（互動層面）的需求與C端很相似，但對產品設計者的難點在於，C端專案的場景一般是由固定的，不會有太多變化，或者說是由團隊一起構思並確定的，這個場景由產品方說了算。

而對於B端，尤其是較為冷門的行業，場景的特殊性會讓產品設計者一時間摸不到頭腦，或是無法在已經成型的行業審美下再做創新，所以產品設計者在這一類產品設計進行時，一定要把特殊的業務場景透過原型圖描述清晰，甚至新增關鍵的註釋。

反思近兩年來的B端經驗，還是建議各位同仁將原型圖儘量繪製得具象，因為在甲方領導的眼中，原型圖比白紙黑字的方案和PPT更具說服力。

還記得自己做得最好的一次也是在某石化園區的OA專案中，當時我採用ANT 2。0的元件庫進行OA移動端的繪製，在彙報中，有位領導突然站起身說，那咱們現在就發一個審批試試，當時這個舉動也為我個人在新團隊的立足打下了基礎。

（4）切忌過分延申和發揮，蜻蜓點水，過猶不及

這幾年的產品工作結識了不少的產品經理和專案經理，大家在專案工作上各具特色，但也有這麼一類人，喜歡在彙報過程中過多描述基礎性問題，或者在與其他產品經理配合時願意在別人已設計好的功能邏輯上增添不必要的功能，甚至擾亂原有的功能邏輯，其實這在團隊和甲方領導眼中是不太容易被接受的。

並且在不懂或不夠了解的技術和業務範圍內過於張揚發揮，卻不能合理說服團隊和甲方，這樣的行為實是過猶不及，分享這個點，願與各位同仁互相提醒。

2.再對合理化設計的總結

（1）介面清晰，主次功能明瞭

能理解的不贅述，不能理解的儘量最佳化，新新增的創意功能要易讀（使用者易理解），講得清。

介面清晰，主次功能明瞭，是多數B端使用者最基礎的視覺需求之一，因為他們希望點開介面就可以馬上解決自己的業務問題，而不是指望在介面上玩互動遊戲。

過於複雜和隱晦的介面設計，即便是垂直這個行業的專家也會惱火，那麼具體到介面設計上，這裡列舉一些需要經常注意的問題。

①

功能主次分明

即該使用者或多個使用者角色在當前頁面高頻操作的功能要擺放到最核心明顯的位置，次要功能需控制好當前介面的設計佔比。

②介面資訊簡單易懂

即介面必要的註釋，語句要精煉簡單，專業性名詞要有特別註釋，其次，這裡也特別提醒多數產品經理和UI常常會犯錯的一個點，就是當前介面的【上傳】與下個介面或彈窗的【提交】本是相同資料的處理，卻因為文案的不同，讓使用者不敢點，不會用。

（2）謹慎思考並使用高效互動

以訂單、合同、審批介面舉例，對於絕大多數公司而言，訂單、合同及審批單是最重要的業務憑證，為了防止使用者操作時出錯，所以此類介面多數是分為2-3步，甚至更多步完成，所以【#高效互動】不見得是在UI層面的簡潔高效，而是以下幾點：

系統能依靠內部或設定的業務邏輯自動進行關聯和計算的操作或判斷，儘量避免讓使用者操作；

在當前頁面足以完成的任務或操作，避免跳轉到其他介面；

對於80%的操作或需要的資訊，使用者3次點選以內就應該可以觸達完成；

能夠識別核心使用者行為，並在他們進行操作時給予對應的指引。

（3）產品設計一致性原則

B端產品的場景多變，業務複雜，角色之間的資訊差異量大，保持產品設計的一致性，不僅是降低使用者的學習成本，統一產品（或合作企業）的風格形象外，從整體專案推進與協同上，也至關重要。

回憶之前任職某石化園區的產品時，產品由1。0版本後交接到我手中，由於我個人的原型繪圖風格與之前產品的截然不同，導致在第一次方案彙報中，我需要向甲方補充很多解釋，但團隊內部卻較為認可近乎於高保真的原型設計。

而在隨後的多個專案跟進中，我發現不同的產品繪圖風格和UI風格會造成甲方誤解，同樣也會造成研發團隊的誤解。

所以，在做B端產品設計時，若有充足的時間和絕對的能力，可以將先前的風格做統一更新美化，畢竟團隊和甲方都喜歡更具象的產品表達。

反之，若專案彙報和實施的時間倉促，則需保持設計一致，節省時間和精力，去做更重要的事。而保持一致性設計除介面元素樣式外，從業務邏輯和結構框架上也需具備一致性，總結如下：

①業務邏輯一致

不同模組或介面的同類功能，採用相同的操作；

同樣的定義或功能需要使用同樣關聯性的標題或文案（如：修改–儲存編輯–儲存/釋出）。

②結構層和框架層一致

即各級導航選單結構、介面的框架和佈局，如：“更多”的入口是彈窗或跳轉介面，選單互動下拉或側滑，操作區域居中或居於介面某側。

③表現層一致性

即核心控制元件、元素、互動動作一致，如：

常用控制元件：按鈕、圖示、toast提示、彈窗、遮罩層、選單等；

常見互動動作：點選效果、滑動效果、轉場動效等等。

二、B端如何讓自己的產品設計更有態度？

提到態度，於B端產品設計而言，可以引申出的詞彙即是個性，圍繞這個“個性”，我們聊聊。

1.讓使用者適當等待，載入即是態度

好的B端產品能對業務和資料有足夠的創新和研發，在資料表達上，適當的互動控制可以增強資料的真實感，也會使使用者更放心。結合過往經歷，與大家一起構思這樣一個場景：

某企業後臺需獲悉當地這一季度氣象資訊及農作物產量及交易情況，透過各種裝置和軟體技術的支援確實可以做到資料的秒速呈現。

但對於使用者來說，資料的獲悉速度並不是他們想要的，而是資料的真實性、準確性以及可用性才是他們必需的。

在這個時候，產品設計者在資料呈現的前一步加上一個【資料載入動畫】，適當地讓使用者等上2-3秒，這在使用者體驗上就會給人以【放心、真實】的感覺，這也是一個數據類產品應該具備的表達態度之一。

2.風格化場景設定

風格化，顧名思義，給到產品對應的風格，在一個產品的理論設計階段，產品設計者雖不需要完全以UI的水準來向內部團隊或甲方領導彙報一份產品設計。

但回憶這兩年來的產品彙報工作，多數國企領導在專案討論中會高頻注重產品的風格樣式，強調介面的佈局、用色等各種細節，甚至也會因為一份產品原型的設計表現決定這個專案是否繼續進行，或該不該如此進行。

像石油化工行業的應急救援、故障巡檢專案，工程建築行業的AR、BIM應用專案，以及某城市智慧大腦專案，在對這些專案進行產品設計的過程中，很多資料資訊都需要更具象生動地表達，才能讓甲方領導一眼會意，這就是他們想要的。

下方分享一個之前本人負責某石化專案的應急救援大屏設計原型圖，以及一張BIM應用設計原型圖。

某應急救援專案視覺化大屏原型稿

某BIM+AR應用專案原型稿

3.資料加工

B端的資料加工需要有新意，而這個新意也一樣離不開一個名詞【合理化】。

產品設計者在對資料動手腳之前，並非簡單地設計加減乘除，為了資料化而資料化，而是以一套完善科學的B端產品資料分析方案為基礎，結合行業資料特性和優劣勢，考慮當前專案所需加工的資料，以及列出充分的理由說明並論證這些資料對使用者會帶來哪些業務方面的提升。

資料分析離不開業務分析，這裡也推薦大家去讀一篇我在站內看到的關於B端產品業務分析的一篇文章，連結如下：http：//www。woshipm。com/pmd/3053893。html

下面分享一張B端產品資料分析流程：

4.元件庫應用設計

B端產品設計初期，一個好的產品也需要具備專案管理的思維，首先要考慮到甲方業務會頻繁變動的特性，以及後續版本持續最佳化、團隊擴張問題。

在原型圖設計和UI設計開始時，不論專案是否龐大，產品負責人除要求和規範繪圖標準外，相應地結合對該專案整體的理解滲透，將可以固定下來的功能元件分門別類，甚至是以文件或更便捷的工具管理。

回憶過往專案經歷，做得最好的一次也是因為研發團隊的夥伴們勤奮積極，我們將採購和自研出的功能元件通過後臺做統一管理，並能向甲方提供自定義配置功能。

若有個別同仁對元件的理解不夠清晰，則可以頁面懸浮框、樹形結構、導航及選單樣式、頁面計算器、主題色切換控制元件等用以理解。

除此之外，更深層次的元件則是功能元件，小到一個前端的地圖定位功能，郵箱功能，大到一個引數管理模組，由於我個人在這方面還需多提升見識，這裡不多贅述。

重點-對於元件庫的設計和管理，其優點在於：

滿足B端使用者對介面的中度定製化需求；

加快研發團隊後續對產品最佳化的效率，減少研發成本投入；

提高B端產品的複用效率。

考慮到大家的閱讀習慣，也為了讓自己在接下來的幾個問題撰述上可以有條不紊，少講廢話，我將在第2、3篇儘量結合行業案例來與各路同仁分享，望參閱。

本文由@嵐烽原創釋出於，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議