對于產品設計師來說，基于嚴謹縝密的思維與過往積累的經驗，考慮全面各種可能的邊界場景狀態，輸出邏輯完整清晰的設計稿是一項比較基本、重要的素質。但有的時候，產品的業務架構會很復雜，牽涉到的目標人群也很多，甚至相關的市場戰略目標也在瞬息萬變；若果我們仍在一開始就對各種場景細節近乎面面俱到地追求，則難免會陷入為兼容各種復雜邏輯而糾結痛苦的境地。

好不容易絞盡腦汁想出一個看起來邏輯完美、各種可能的需求行為都兼顧到、咋一看無可挑剔的方案，卻走入各種尷尬境地：考慮了所有可能的操作路徑，最終呈現的界面卻不能被多數用戶認知理解；為某個潛在場景精心設計了一套流程邏輯，整體復雜度也直線上升，卻發現最終真正用到的人寥寥；因為涉及到的開發工作量大、對于短期業務目標的提升又不明顯等緣故，被優先級的大棒直接砍掉最后不了了之……

大眾用戶與專家場景

產品可能需要同時服務于好幾類用戶，而各類用戶的需求存在差異甚至矛盾沖突，如果一開始就想著把所有用戶的所有潛在需求場景都考慮到，不僅設計過程中會糾結，最后的產出也難逃給人復雜的印象。

有時候，一些造成設計復雜度上升的功能，并不會被80%的大多數用戶介意，而只有少數的專家用戶有用到它們的場景；專家用戶可以相對輕松地理解和使用這些高級功能，但當它們呈現在大眾用戶面前的時候，卻會讓后者產生困惑甚至畏懼的心理。

當這些專家用戶并非我們產品的核心目標用戶，或高級功能于他們來說只是對體驗影響不大的錦上添花時，不妨嘗試對這些影響整體設計復雜度的功能做做減法，使用如《簡約至上》里刪除、組織、隱藏、轉移的四大原則，保證呈現給大眾主流用戶的使用場景是簡單的，而復雜藏匿在背后角落。

復雜也許并不存在

當需求方提給我們一個復雜的設計需求時，要追問清楚具體的用戶使用場景和背后業務緣由，驗證復雜設計需求的必要性，而不是強行yy出偽場景并為此糾結。對場景的完美主義讓我們為復雜而痛苦，但復雜本身可能并不存在。

有時我們可以憑直覺感受到復雜的需求本身不是很站得住腳，但說服對方砍掉卻困難重重，這時就要更依賴數據或用戶來說話。比如可以圍繞這個需求快速出一個粗糙的 Demo，找幾個真實用戶或非常熟悉真實用戶的人測試，詢問他們是否在意這個功能，是否有想用到它的場景，還是覺得可有可無或者根本用不到；而不是強行根據需求倒推偽場景，陷入根本沒有存在必要的糾結。

拆解排期與主動跟進

經過了減法的整體設計方案，也可能仍然會需要較大的開發工作量，在上線時間緊迫的時候被 PM 根據優先級選擇直接砍掉幾個模塊也情有可原。于是有時我們發現自己耗費心神想出各種方案，最終卻白白浪費了精力。

若一味聽信他人隨口說的「之后再上」，而缺少自己主動去跟進和推動的意識的話，有可能「之后再上」會慢慢變成「永遠上不了」。

市場、戰略和目標用戶不會一成不變，項目每一階段的業務目標也會有調整。除了關注當前手中的工作之外，也要帶著更全局、前瞻一點的意識去規劃未來的產品設計。了解項目組中長期的規劃藍圖，根據各階段業務目標拆分和調整設計方案并與大家達成一致，在每一階段主動跟進一部分設計方案的落地上線，而不是讓設計稿永遠淪為飛機稿式的存在。

本文由人人都是產品經理專欄作家 @鴻影 原創發布于人人都是產品經理?。未經許可，禁止轉載。