編輯導讀：B端產品多種多樣，設計過程中會遇到不同的問題。本文作者從自身工作實踐出發，對招聘SAAS系統設計展開分析，并基于自己的思考，對設計過程中的一些問題進行了解答，供大家一同參考和學習。

從0到1的SAAS系統多是由公司自上而下推動開展，因此今天我不會和大家過多說明項目的背景和緣由，而是著重和大家聊一聊在從0到1這個階段，我們經歷過的困境以及破局之法，希望可以為大家在從0到1設計SAAS系統以及后續的迭代過程中，提供前車之鑒及較為落地的解決辦法。

困境一：種子客戶的定制化需求/客戶需求和產品規劃不一致

兵馬未動，糧草先行。在產品團隊開始規劃設計系統之前，銷售已經開始打單，并且拿下了一個行業龍頭客戶。

即便我們前期做了很多業務調研，系統冷啟動的過程中，不可避免地仍會依托、參考借鑒種子客戶反饋的真實業務場景，這也注定了接下來的很長一段時間我們都處于被種子客戶裹挾的被動局面中。

該客戶會根據自己過往的系統使用經驗及線下業務場景提出大量需求，而這些需求無法通用化，此時，尋找種子客戶定制化需求和通用化場景之間的平衡點至關重要。

針對此類大型種子客戶，若無法滿足他的使用，可能意味著失去，對于開拓市場極為不利?？梢园凑找韵聨c進行逐步實施：

1. 尋找影響其流程使用的核心點，如果人力和時間極為有限，盡可能以最低成本去實現，滿足客戶的使用；若功能有通用化的方案，可結合功能設計、實現邏輯、實現成本，判斷是否允許后端先以配置化進行開發，節省后期通用化開發成本；
2. 針對不影響客戶使用的功能點，可采取“置換方案”，即以告知客戶正在規劃和進行中的功能的實現價值，來置換客戶一些不太重要的功能點；
3. 拒絕一些需求，主要是一些僅僅解決客戶當下需要，但后期可能并不會用的需求，可告知客戶其他解決辦法或研發一次性處理掉，無需通過功能性進行實現。

困境二：不同類型客戶的多樣化需求

在客戶數量漸漸增加后，會面臨不同規模的客戶?？蛻舻脑V求也不盡相同。以招聘系統為例，大型乙方客戶的業務流程較為規范、業務類型較為豐富，所需功能可能不僅限于職位管理、招聘流程、人才庫、報表等核心功能，還包括客戶管理、開票管理、供應商管理等功能；而中小型客戶的業務流程簡歷、業務類型相對單一，所需功能可能僅有部分核心功能，甚至僅需要人才庫。

那么在針對整體系統給迭代過程中，如何處理不同類型客戶的不同需求，甚至同一種功能的不同要求：

1. 所有需求的迭代圍繞客戶留存風險、功能價值兩大要素圍繞進行；
2. 高價值、高風險客戶的核心需求為第一優先級；低價值、高風險客戶的核心需求次之；整體需求排優過程中，盡量保證需求的通用性。

困境三：功能邏輯高度耦合

在從0到1系統設計過程中，一個無法避免的問題就是各個功能模塊見的邏輯耦合。由于不同功能由不同產品負責，功能邏輯高度耦合時，容易造成產品設計的邏輯漏洞（因為可能會遺忘），同時容易造成后期產品邏輯過度繁重，也不利于用戶使用。

可通過以下幾點來盡量避免邏輯高度耦合造成的設計應影響：

1. 產品設計前的充分溝通，確保涉及邏輯與其他模塊的功能不會沖突；
2. 設計的邏輯盡量考慮是否涉及到權限部分。舉個例子，當用戶沒有查看職位的權限，但是卻具備招聘流程的操作權限時，如何可以看用戶投遞的職位詳情，可以考慮采用彈窗的方式來解決，確保用戶可查看職位詳情，避免因為無職位數據權限造成無法在其他功能中查看職位詳情。

困境四：客戶永遠在猜測功能的邏輯

客戶使用系統時，會拋出大量的使用問題和功能實現問題。比如客戶在導入簡歷時，會問一系列問題：最多可以導入多少份簡歷？簡歷重復時是否會有提示？重復的簡歷是怎么處理的……

產品設計時，盡可能將功能做一些必要性地解釋說明（說明的展現方式有很多種，可以直觀說明，也可以以hover時展示的形式進行，具體案例具體分析），不要讓用戶去猜這個功能是做了什么，之后又是怎么處理的，否則會造成用戶使用的疲乏感，也容易增加解答客戶問題的時間成本，得不償失。

困境五：差勁的交互設計

用戶在使用過程中，經常會問這個應該怎么操作，為什么這個無法點擊，為什么這個點擊后跳轉到這個頁面。

系統的用戶參差不齊，功能使用上的諸多疑問不要歸咎于用戶。產品需要考慮每一個點擊跳轉的合理性、操作項交互方式的必要性、操作路徑的簡潔性等（如果交互設計師，則可盡量與交互設計師溝通、反饋，避免此類問題重復發生）。

綜上所述，在設計SAAS系統過程中，切勿被客戶牽著鼻子走，更不要忽略良好交互的重要性，須清晰了解產品功能間的邏輯耦合，簡介明要地展示功能設計的說明和邊界。

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

題圖來自?Unsplash，基于 CC0 協議