上一篇 B 端和 AI 分享中，重點提過 B 端設計師要加強對全局的認識，以應對新的行業挑戰和機遇。

但問題是，如何加強對全局的認識？第一步肯定是多用 B 端產品，但 B 端不像 C 端我們每天都在使用，往往非常隱蔽難以接觸到，對于沒有什么項目經驗或者準備開始學習的新人來講非常陌生。

雖然我們過去整理過可以直接注冊登錄的 B 端 SaaS 平臺，但沒有目的性的去胡亂看一通是沒有什么幫助的。必須要掌握一定的思路和方法，才能從開源的產品身上理解吸收經驗，提升我們對 B 端產品的全局認識。

一、B 端產品的研發思路

試用產品除了了解頁面設計的樣式、功能、交互以外，還要去了解它背后的設計邏輯，更宏觀層面的考量。

而要滿足這一點，首先就要知道 B 端產品的研發邏輯，才能在自己的使用過程中進行逆推和更深入的思考。

一個常規的 B 端產品研發流程，可以總結為下面這個循環：

第一步也就是最關鍵的一步，即總結業務需求，那什么叫業務需求？即企業運作實踐中所產生的需求，要通過數字化產品來解決。

比如一些很常見的情況：

1. 需要全體員工上下班考勤的統計，作為績效評定的標準之一
2. 需要記錄門店物料的進出狀態，用于每月底的財務審核和進貨依據
3. 需要一個專用的企業任務管理工具，用于從上到下完成任務的指派和跟蹤
4. ……

正常的 B 端項目，是由業務導向的，如果沒有業務需要，就沒有它存在的價值。而很多新手和初級設計師會一直把 B 端需求歸因為“甲方的任性”、“老板的天真”，用虛無主義來消解一切市場行為，這顯然是沒有意義的。

因為 B 端產品如果不能解決問題，那么投入成本研發它有什么用，資本都是大風刮來的嘛？

不排除有些項目從立項到成果都很糟心，但代表不了所有項目都是這樣的，而優先關注 SaaS 類產品也有個好處，就是它們都建立在非常明確的業務場景和目標之上，因為產品做的不好，解決不了客戶的業務問題，那就不會有人買單。

有了業務需求，才會制定對應的功能點和產品服務。如果產品包含的功能板塊越多，就證明它所要滿足的業務點也就越多。

然后，設計師才會在功能要求上制定交互的邏輯以及具體的界面樣式，程序員再把它們實現出來，完成后續的上線。

而上線以后不代表產品的研發就結束了，除了還沒做完的需求外，上線的產品還要在應用場景中收獲用戶的反饋，需要結合它們制定后續版本的需求。

所以，一個經歷過長時間發展和迭代的產品，變成今天這樣是多種條件共同作用的結果，可以根據主次總結成下面這種狀態：

第一級：業務需求

第二級：功能需求、用戶需求

第三級：設計水平、開發水平

這種結構類似用戶體驗五要素，但和五要素不同的是，我們的全局分析不能只圍繞“體驗”展開，因為 B 端是業務驅動不是體驗驅動，用戶的優先級遠遠沒有業務高。

而體驗 B 端產品的時候，就可以根據這個分類去做解讀。首先是功能反映了它要滿足哪些業務需求，具體應用場景是什么樣的。功能點有哪些，以及相關的邏輯。且哪些功能是基于用戶需求和體驗制定的。

然后再分析細節層面的，基于業務、功能、用戶的影響之下，設計的表現水平如何，一些能感知到的技術應用是否能滿足現有的要求。

雖然分析順序是從上而下，但我們體驗一個產品必然是先接觸到最底層的細節（界面和交互），而這就會讓設計師直接陷入細節不能自拔，開始關注按鈕、色彩、組件、表單等內容的視覺和體驗，再用不同的理論去套用分析。

雖然細節分析對于設計師來講是必要的，但我們今天的主角是全局的認識，只關注細節的做法是不能幫助我們獲得提升的，所以從產生的接觸到使用上，我們從一開始就要奔著宏觀的層面而去。

就像企業主、真實用戶去使用產品，很少會優先關注界面好不好看（或者根本不在意），原因就是他們的關注點不在這里，而在更有價值的地方，這也是我們要培養的能力。

所以想要提升產品全局認識的話，那么使用 B 端產品的路徑如下:

別以為這是個復雜繁瑣的流程，其實操作起來并不困難，下面我就會基于新手的現狀建立一個從簡單到復雜的學習增長路線。

二、B 端產品的使用路線

前面說過，對于大多數人來講，接觸的 B 端產品并不多，沒有相關行業經驗和知識的積累下，就是進入了軟件內也是兩眼一抹黑啥都用不懂。

比如面向開發、運維的云服務、Devops 類產品：

或者面向物流、進銷存的 ERP、SOP 類產品：

雖然這些專業性的 B 端產品離我們很遠，但不代表我們日常學習、工作中就完全用不到 B 端產品。想要建立對它們的認識，就要先從和我們生活關聯性較大的方向入手。

我的建議是根據難度依次去體驗后續三個類型的產品，第一是 TODO 類工具，第二是文檔類工具，第三是電商類工具。

前兩個在早年都只有純 B 端應用，隨著 Web2.0 的發展，個人用戶也對這類產品有非常大的需求，所以它們逐步開放給個人用戶，是 B 端 C 化的主要應用場景。而電商類工具，則是因為我們網購經驗實在是太豐富了，所以理解成本很低，并且電商類系統的功能覆蓋面非常廣，可以很好幫助我們延展對 B 端系統的認識。

下面我們分別對每個類型的工具使用進行介紹：

1. Todo 類產品

Todo 類產品就是待辦事項管理工具，現在完全面向的 C 端的待辦工具不少，比如滴答清單、日事清、Things 等等。但既然我們要上手 B 端產品，就要選擇以 B 端為主的工具，比如國產的 Teambition、Worktile、Tower，或者國外的 Terllo、Asana 等等。

這類工具也叫項目管理軟件，是在敏捷模式大火以后普及的，最基礎的任務管理模式就是使用 “kanban” （這是個日文，英文就那么些，直譯也是看板……），將任務拆分成不同階段，每個階段下的任務用卡片進行羅列。

先到這些產品的官網看它們介紹，選擇個自己看得爽的直接注冊登錄進去使用，然后用它來做你們的生活待辦清單或學習待辦清單。

比如我們創建一個項目，把任務拆分成四個狀態，考慮中、準備做、進行中、已完成。把你近期工作或學習的任務添加進去，然后結合它來完成你近期的工作事項。

當然，這個分類不是固定的，你們可以自己調整。在使用的過程中你肯定會產生各種問題，從而去產品中找對應的功能或實現方法。

2. 文檔類產品

文檔類產品就多了，前面寫過專門的文檔演變過程，C 端產品不勝枚舉，而這里我們主要關注一些面向 B 端為主的文檔工具，比如石墨、騰訊文檔、飛書、語雀等等。

同理還是了解完選擇一個自己喜歡的，然后去搭建個應用它的場景。如果還只是自己用，比如創建個人的筆記之類的，就沒意思了，不會體驗到它們的協作精髓。我會建議你們去創建一些需要多人共同協作的場景，比如和朋友創建訓練計劃，和同好共同整理資源，和群友共同編寫知識庫等等。

有了目的，再去使用這些文檔工具，你們就要自己去梳理對應的目錄，制定文檔內的格式，協調編輯的路徑，確定改動的邏輯等等。

因為現在的文檔工具已經非常復雜，所以他們呢可以提供非常多的功能和操作方式，可以讓我們投入非常多的時間去研究它們應該怎么和我們的需求適配起來。

是繼 Todo 應用后最適合上手應用的工具類型，也因為它們太復雜，并不建議大家前期用文檔工具作為 Todo 工具體驗（當然這個也可以自己試試）。

3. 電商類產品

最后一個電商類產品，其實就是電商的店鋪管理工具。比如淘寶的千牛、有贊、微店等，就是可以直接開店并管理店鋪的工具。

這里我們要做的就是模擬一個開店的過程，去操作這些產品。當然沒目的性開店是沒有意義的，你可以挑選個你喜歡的店鋪或品類，搬運它們現成的素材到自己店鋪里，并創建 10-20 個商品。

從開店填寫信息，到上架商品編輯內容，是一個非常復雜、繁瑣的過程，但中間的大多數步驟你們都能理解為什么要做這些操作。所以過程越繁瑣，中間就會有越多能讓你覺得困惑或是問題的地方，對于我們深入理解業務和產品的聯系有非常大的幫助。
如果條件允許，我也建議你們盡量自己上架自己拍商品走完整個流程（不同平臺、品類門檻不同，要自己研究下），再體驗下單、發貨、提現的不同環節。

在上述的體驗過程中，我們構建的應用場景，就是業務的需求，而使用這些產品就是去解決業務需求的過程。產品能不能滿足你的需求，如果能是怎么滿足的，沒滿足的話是為什么，缺少什么東西？這些親身經歷是理解 B 端產品的基礎，而不是只隨便看看頁面按按按鈕來分析產品的體驗。

有了這些經歷，就可以從宏觀去分析產品面向的業務需求是什么，它們提供了哪些功能和服務，是否可以滿足。而這些功能、服務應用了什么樣的交互和信息，操作體驗好好不好。最后才是視覺這些細節的完成度，還有哪些問題和改進空間。

這種思維在實際項目中也不一定能鍛煉到，很多工作了幾年的初級 B 端設計師仍然不具備這種能力，所以必須依靠我們自發去訓練。

而經驗的累計，可以幫助我們在完成新的項目或改版的時候從更宏觀的角度看待問題，輸出一套界面或者規范不再只是立足于一些“無關痛癢”的設計理論，而是要配合業務、功能盡量去解決 “上層問題”，創造更多的價值。

結尾

上面的操作建議所有已經從事還是想要從事 B 端行業（不管是設計還是產品）的同學去實踐，只沉浸在視覺、體驗的設計中是永遠不可能在國內 B 端領域“進階”的。

當然，會真的實踐的同學必然是少數，所以這部分人會在認知上遠遠超過另一部分懶于實踐的人，在職業發展中上升到他們無法企及的緯度。

想學系統完整的B端課程，看這里 ?? https://pro.uisdc.com

下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」