只有對需求有清晰地認識，我們才能定位要通過設計解決的問題，為給出正確的設計提供條件。如果對需求的認識是模糊或是錯誤的，那無論你怎么努力都只能做出錯誤的設計，而且會有大量的反稿，浪費團隊的時間。

用戶需要什么樣的產品呢，形形色色的用戶并不會記得自己說過的所有話，他們只會記得他們想要的，而不想要的都是產品設計人員強加的，用戶需要的產品一定是能解決某個具體問題的產品。

用戶按照使用熟練度的維度可以分為專家型用戶、隨意性用戶、主流用戶。

第一類不用說一般是技術狂熱者，他們舍得花時間研究新產品，探索產品的新功能，他們愿意暢所欲言，對如何改進當前產品固執己見，但他們不是典型用戶，他們的判斷會出現偏差；他們不會體驗到主流用戶遇到的問題，可能總對會飛的汽車感興趣。

第二類是隨意性用戶，他們可能使用過類似的產品或服務，他們有興趣使用更高級更復雜的產品，但卻不愿意接觸全新的東西，要想讓他們認可新功能，那么新功能必須足夠簡單。

第三類用戶是主流用戶，他們自己不會因為你的技術而使用你的產品，使用你產品的目的是完成某項任務。他們會掌握一些重要功能的使用方法，但永遠不會產生學會所有功能的想法。

這些人的口頭禪就是：“只要能打電話、能發短信就行了”。

大多數人屬于這一類，以前總是覺得用戶使用產品一段時間后就會轉變為資深用戶進而成為專家，后來發現完全不是這樣，和使用時間的關系不大，就像同事每天從同一個地鐵站進入的A口進站，但是有一天你問他A口有沒有廁所時，他說沒注意到過，即不知道。

正如Giles Colborne 所說個人對產品的態度與他們在使用產品或服務上花費的時間相比，前者對他們的影響更大。

很多時候用戶其實沒法說清楚，也可能無法描述出問題的根本，說了很多現象與場景，復雜的根源需要產品人員去探索，用戶要買的其實不是某個產品，而是他們需要運用一個產品來完成某種任務或解決某個問題。但產品又不是直接由用戶去生產的，用戶可能只會說“我要一匹更快的馬”或“我要一輛跑的更快的馬車”，產品人員卻需要透過表層去理解、不斷的問為什么，直到把用戶的真實需求理解。

如果失去思考，那么軟件就會被用戶牽著走，如“這里為什么沒有打印，我們經常要打印呀”，“這里為什么沒有合計呀，我們還要用excel再計算一次”，“這里為什么不支持全部導出呀，我還要一頁頁的選”，漸漸的功能不斷增多，軟件會變的臃腫，甚至連按鈕都沒有地點放，就像那個古老而復雜的遙控器的按鈕一樣，頁面上到處是各種各樣的操作按鈕，使用者最終也會發現每次要做一件事時都要思考該點擊哪個按鈕。

而且B 端的設計難點不在于精美的外觀和復雜的設計，而是要符合產品的實際需求，并有效提升業務運營的效率。

那么對于 B 端產品人員最大的挑戰其實是理解需求。

只有對需求有清晰地認識，我們才能定位要通過設計解決的問題，為給出正確的設計提供條件。如果對需求的認識是模糊或是錯誤的，那無論你怎么努力都只能做出錯誤的設計，而且會有大量的反稿，浪費團隊的時間。

認識業務需求

在 B 端的項目中，需求來源是市場人員與客戶的反饋、相關部門的業務場景。當然，在一些特殊的情況下，可能是老板或者客戶的口頭描述。

但無論什么形式，B 端產品的需求，是由業務的需求衍化而來。例如，在一個電商平臺，本來只銷售服飾類產品，但隨著業務的發展，引入了新的鞋靴品類，那么原本的產品創建流程就需要調整，比如增加下列需求：

• 創建過程增加品類選擇，方便數據庫分類和篩選操作；
• 選擇鞋靴品類后使用于服裝不同的商品屬性，尺碼由字母改成數字；
• 創建鞋靴的客服專員角色，并分配對應權限和接口；
• ……

所以，B 端產品的需求，是因為業務上有需要，所以才制定，而不是產品經理憑空想象，覺得這個功能很厲害，用戶一定會喜歡就直接做上去。

那么對于商業一竅不通的設計師，該怎么分析和產品需求相關的公司業務呢？可以通過以下的步驟來解決：

確定業務目標

對于企業日常的運作，每一條業務線都需要消耗人力成本，形成支出，所以在制定時，我們對它的預期就應該是能為企業帶來收益，雖然有時候這種收益不是直接的盈利。

我們第一步要做的，就是先撇開所有業務有關的細節部分，去發現它所要達成的目標和預期。比如：前面提到的新增一條產品線，目標就是為了擴大銷售品類滿足顧客的需求，增加營收。

當然，一些比較大的目標，理解起來很容易，看起來也很清晰，但只得出這個結論對業務的理解是遠遠不夠的。無論是企業還是個人，一個遠大的目標，都要由若干小目標所組成，即實現這個結果的條件。所以，我們還需要去找出實現這個目標所要達成的其它目標。

這就是一個比較艱難的任務，因為它涉及諸多商業問題。所以，要明白一點，多數時候光靠自己的思考是得不出答案的，我們該做的是去請教了解或者熟悉這個業務的同事，一定要有目的性主動去了解，而不是等待別人一條條和你說明。

然后，我們就要把獲得的結論用筆記或思維導圖軟件串聯起來，分析這個業務目標的完整性，比如下圖：

這是一個我簡化后的業務目標拆分，在真實的項目里往往比它更復雜，且我們可以針對一些非常重要的二級目標再進一步拆分，這就要根據大家對業務的判斷來進行了。

做好了這些內容，就能對當前產品有關的業務內容，有一個清晰的認識，即使是你完全沒有接觸過的行業也可以用這樣的方法獲得宏觀上的認識。

繪制業務流程圖

接著，我們要做的，就要把目光從概念落實到實處，即公司在實現這些目標時的具體執行方式。

可能有同學接觸過產品流程圖，業務流程圖和它比較像，即實現目標結果所要進行的一系列實踐，但不同于產品流程的特點是，業務流程的執行過程更「線性」，不需要表現出太多的布爾和循環。

比如我們對能正確選品展開分析，那么在整個確定選片的鏈條中，它的執行步驟如下：

同理，我們也可以以這樣的方式畫出其它目標的流程圖。之所以我們不把整個業務流程在一幅圖中畫出來，這是因為包含的步驟太多會導致流程圖可看性極差，且不同的目標執行并不一定具有強關聯性或先后順序，所以拆分才更合理。

掌握這部分內容是至關重要的，因為未來我們在理解產品具體的需求和制定交互流程的時候，都要與業務流程進行關聯。

還要注意的是，如果時間不夠，繪制和維護這些圖形又需要大量時間，那么我建議使用類似 MarkDown 之類的筆記工具直接記錄，提升效率，不要被「圖形」的字眼給束縛住。

總結角色職能

所有業務的實踐，除了一些自動化的器械和程序以外，主體都是人。但人會被分配到不同的崗位，不同的權限和責任，所以我們能參與業務的所有成員定義出「角色」的分類。

例如，在前面的流程案例中，確認選品到篩選目標商品的執行，都由商品運營人員處理，到了評審階段，就會涉及到市場、總監、老板等其它角色，提交采購訂單還涉及到財務，最后驗收入庫由倉管完成。

我們不僅要找出角色對應到業務流程的事件，還要確定他們在這個事件中發揮的作用。在我過去的制作習慣中，會喜歡將角色做成一個標示符號，然后對應添加到流程圖中，并進行對應標注，如下圖所示：

這種方法可以進一步降低整理材料的復雜性，能讓我們輕易看懂，即使在團隊內部討論的時候也方便分享。

找出優缺點

最后，就是對我們已經做完的內容進行總結了。在這里，我們要找出的優缺點，不是像職業經理人一樣去優化業務流程的反思，這不僅超出了我們的職責范疇，也不是設計師的眼界和經驗能夠體會的。

雖然說要找出的是優缺點，但實際我們要做的是發現當前流程體系內的問題。

那么什么是流程的缺點？這點除了我們自己的想象以外，還必須主動去觀察和溝通，每個事件的相關角色對當前遇到的問題感受是最清晰的，我們需要通過咨詢他們來最終完善所有結論。

比如，商品運營分析用戶評價的時候，當前的后臺評價列表缺少篩選功能也不能導出 Excel，結果需要依靠翻頁手動記錄，非常耗費時間，那么這個缺點就會演變成為產品的需求之一。

這樣，我們就可以把業務中出現明顯問題的步驟進行標注，同樣是通過在流程圖上標注完成。

當然，很多時候我們獲得的產品需求中，就會包含對于業務問題的分析，我們也需要將它們直接和業務流程關聯起來，具體處理的位置在哪里，有哪些角色參與其中。

完成這一步以后，我們對業務的認識就會有質的改變。這時候，我們就可以用自己的角度去判斷，當前產品給我們的需求是否符合實際的需要，接下來我們要做的交互和設計，到底是在解決什么樣的問題，對整體的目標實現，有什么樣的幫助。

總結

雖然這些內容看起來很麻煩，但是只要自己嘗試做一次，就一定會獲益匪淺。

尤其是對于完全不了解當前產品解決問題和公司業務內容，被用戶牽著走的時候，我相信你們嘗試執行一次以后，就不會再對自己當前的工作感到迷茫。

本文由@山人小道 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議