在產品設計的工作流程中，設計師有時也需要參與到需求評審、需求設計等階段中，這個時候，設計師要怎么避開需求評審或需求對接中的“坑”？本文作者便結合自身經驗進行了總結分享，一起來看看吧。

通常設計師會參與到需求評審、需求設計、設計評審、研發跟進、設計驗收幾個階段。在每一個階段，設計師應該都踩過“坑”，本文主要復盤作者在需求評審（需求對接）里遇到的典型問題，并分享解決辦法。

需求評審時需要思考哪一些內容：

1. 需求背景是什么（用戶是誰、遇到什么問題、怎么解決問題）。
2. 需求上線想要達成什么樣的目標（量化指標）。
3. （產品介紹方案后）初步思考功能能不能實際解決背景里闡述的問題，有疑惑及時提出。
4. 初步思考實現方式，若產品方案和設計師的認知有很大偏差的情況下，及時提出，避免設計師按照自己的想法修改后方案被pass，因為產品可能基于某方面考量，不得已選擇此實現方案。
5. 確定交付日期，避免產品經理瘋狂催稿（因為設計師可能不止對接一個產品，但是有的產品會想當然你接下需求就馬上開始做，并且給你主觀預估交稿時間）。若交付時間比較緊，來不及完成，可以和設計師商量先完成一部分交付進行開發，后續在補交未完成部分。

一、需求價值不明確

背景：每個季度員工需要填寫KPI和KPI完成情況，季度末領導對員工績效完成情況進行評定，若員工對評定結果不滿意，可以發起績效申訴，然后由HR邀約員工和領導進行面談，并填寫通知申訴結果。

問題：績效申訴在整個公司一年大約0-3起，使用率非常低，值得做嗎？

方法：針對此類型的需求，思考3個方面。

1. 該功能能幫助用戶解決什么樣的問題，是否符合產品目標（降本增效）。
2. 用戶量有多少？使用是否頻繁？
3. 需求投入人力和實際功能上線后帶來的價值是否成正比。

*當然一切的方法都敵不過領導或者需求方的我就是要這個功能，如果需求不合理但是非做不可的情況，可以根據緊急程度適當調整優先級。

應用：

• 該功能能幫助用戶解決什么樣的問題，是否符合產品目標（降本增效）——該功能能夠幫助員工更便捷申訴、HR更快的查看申訴資料。
• 用戶量有多少——申訴的用戶是全公司，處理HR是固定的幾個人之一。
• 需求投入人力和實際功能上線后帶來的價值是否成正比——需求投入人力約48h+ 但是用戶實際使用一年幾分鐘。

結論：1次申訴節約時間成本約4分鐘（根據打字和手寫速度估算，正常人手寫每分鐘25+字，電腦打字每分鐘120+字），研發投入2880分鐘需要處理720件申訴，花費約240年才能大概回本。

當然這個只是大概的估算，一方面HR團隊和研發團隊的薪資不同，無法直接對比時間成本，另一方面過程中可能有別的突發事情是不可預料的，比如申訴資料查找在電腦可能2分鐘找到，但是紙質的可能丟失，又會帶來一系列的問題，需要時間人力處理。

二、產品方案不合理，不考慮實際場景

背景：貨運司機會根據車輛調度員的計劃進行發車，也會有不在計劃內的發車任務，因此設置了加班車&臨時發車的入口，方便快捷登記。

問題：加班車和臨時車都是在常規班車以外的特殊發車，是兩個字段相似且不同性質的兩個登記流程。但是產品經理的方案里只外露了加班車登記的入口，然后點擊默認進入加班車登記，然后通過提交后校驗，決定是否再轉入臨時車的流程。站在申請臨時發車用戶角度，沒有直接入口操作非常不便。

方法：很多時候產品經理給的方案是未經探索和調研，只是功能層面的思考，功能走通即可。因此在對接產品需求的時候設計師需要有自己獨立思考，學會不斷提問（可以采用5WHY分析法）。

應用：

• 為什么要隱藏臨時發車入口——因為加班車和臨時車之間有邏輯需要校驗。
• 這個邏輯是用戶自己能判斷，還是必須系統來校驗——用戶可以自己判斷。
• 那用戶想要直接申請臨時發車的時候怎么辦——只能先提交加班車，再提醒轉入臨時發車。
• 為什么不可以直接申請臨時車——（支支吾吾……）。
• 臨時發車申請的使用頻率高嗎——占場景的80%。

*在和產品對接的過程中，產品不清楚場景是一方面，可能還會基于不愿意承認自己錯誤這一心理要素，給你錯誤引導，所以設計師要學會根據業務理解、競品、參考資料等獨立思考，分析需求。

結論：B端是以效率為本，突出顯示高頻的操作按鈕，可以幫助用戶節省操作成本，提升產品滿意度。

三、場景考慮不全面

背景：連續兩次績效不合格的人會被HR邀約面談，制定接下來的改進計劃，并在績效改進中實時跟進改進結果。

問題：產品經理直接將線下的績效改進表格發過來，然后告訴填寫入口在哪里，就讓設計師開始設計。表面看起來就是一個績效改進填寫的頁面，但是其實流程涉及三類角色，每個角色入口，做的事情都不一樣。

方法：可能基于時間關系和產品做事的風格不一樣，有的需求拿到手里其實是非常表面的，需要設計師先梳理流程和角色，然后基于業務目標進行設計。

應用：

梳理流程：

梳理查看頁面不同角色操作：

結論：這不是一個頁面的設計，入口頁、編輯頁、查看頁、通知，是一個閉環的流程的設計。

四、不清楚要什么

背景：財務總監想要做一個工作臺，方便財務各個角色的人員可以快捷的通過工作臺處理日常工作事項，財務管理者可以通過工作臺直觀的看數據，輔助管理。

問題：需求是財務總監傳達給產品，但是并沒有說明需要哪一些數據和內容，于是產品讓設計除出了一版初稿給到財務總監，然后總監再找到對應角色去詢問使用意見，設計再進行修改，然后再拿給財務總監確認。反復修改，設計成本高。

方法：業務不等于用戶，有條件的情況下可以直接接觸用戶了解真實場景，沒有條件的情況下可以通過業務代問用戶拿到二手資料，大框架一定要提前制定，細節可以逐步完善。

應用：首先梳理工作臺的角色有哪一些，綜合考量角色的共性以及差異進行工作臺草圖繪制，然后拿著草圖找到對應的角色去咨詢意見并針對遇到的問題適當詢問用戶解決方案并修改，再找業務確認。

結論：如果產品或者需求方不清楚要什么的情況下，一定要找到真實用戶詢問場景和探討解決方案。

五、簡單視覺優化就可以

背景：產品經理因為上線時間緊，提前按照原型上線了看板內容，然后才截圖發給設計師說就簡單做下視覺優化。

問題：視覺優化只是好看就行嗎？

方法：任何產品需求都建立在用戶需求之上，設計要有理有據，不要脫離場景做設計。

結論：看板的需求其實和我們做其他需求一樣，需要先了解背景，跟隨業務目標進行信息的整理和布局，最后再做美化。如果你真的只是在現有界面基礎上進行美化不考慮業務場景、交互邏輯，那么很有可能產出中看不中用的產品。

六、簡單做，不考慮擴展性

背景：在一個項目中，功能會分期迭代，但是有的產品經理不管后續功能的擴展性，只考慮當前版本能夠上線。

問題：后續功能上線后和前面的沖突，導致全部重新設計。新功能可能由于數據原因、流程原因、定位原因等，會導致頁面的布局交互重新設計，重新開發，增加了人力成本。并且在時間緊急情況下，可能有的產品經理會選擇不重構，錯上加錯，僅僅為了滿足功能，忽視了體驗。

方法：在接到需求設計時，我們應該充分考慮各種場景和產品后期規劃，盡量保證產品擴展性，減少重新開發。

結論：不考慮拓展性很可能導致返工重新設計或者體驗大打折扣，務必提前了解清楚規劃，盡量避免。