起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識參加需求評審，設計師需要注意這幾個問題
編輯導讀：需求評審會，雖然是產品經理的演講會，但是與會人員卻不是只有產品經理。本文作者從設計師的解讀，對設計師參加需求評審需要注意的問題進行了梳理總結，供大家一同參考和學習。
很多人把設計師的工作單純的定位為【視覺】層面的輸出，好像只要設計稿美美地就大功告成了。但是，我們都知道，其實不是這么簡單。
設計師的工作職責不只在最后輸出的美觀，同樣重要的是產出的過程。需求的產生，需求的背景，需求的解決方案等等。不要讓設計是斷層的，它應該是完整的，有開始，有結束。
01 需求評審前，你不可遺漏的準備工作
設計的前期，PM一般會拉個需求評審會，這時設計師也需要參與到其中，不要等到需求完全確定了，設計才開始介入。有些不合理的需求，應該從一開始就規避。如果PM沒有這個習慣，你可以溫柔地建議他拉你一起。設計師要在產品的開始和結束都滲透在其中，這樣你才能對一個產品整體性更清楚，也更有把握。
需求評審是一件比較費力費時的事情，所以在確定需求評審時間后，可以先請PM給你一份需求文檔，可以先簡單的了解，對于不理解的概念，可以提前自己弄清楚，這樣也可以避免在評審會中提出太過初級的問題。如果是對現有產品的改版，可以先了解產品線上頁面是怎么樣的，這樣也可以更了解需求，也對PM提出的解決方案是否真的解決用戶的問題，有進一步的了解。
我想，這樣的準備工作是需要的，不要一臉茫然的參加評審會，你不需要完全明白，但是至少你要大概了解評審會要評審什么內容。這樣大家在聊需求時，你也快速接上他們的頻率，不要讓他們覺得你什么都不懂，也給不出什么建議，也不提出任何疑問，你只是角落里那個“安靜的美男子”，這樣你就變成可有可無的角色了。
我們都在談“設計師如何掌握話語權”，我想提前了解產品需求會是重要的一步。天下武功唯快不破，設計亦然，當你比別人快一步時，被動轉主動時，就是改變的開始。這是一個好的開始，也是與PM、開發們建立關系的開始，當你慢慢用自己的主動和設計能力建立彼此的信任時，他們會愿意來咨詢你的意見，而不是只當你是一畫圖的，而這時就是你發揮你設計影響力的時候了。
還有一點，提前預備你的時間，檢查你的行程表，避免會議沖突。
02 需求評審中：你要做的事
1. 勇敢提出你的問題
需求評審的初審到確定方案，可能需要2-3輪評審討論。在這當中，如果你有什么疑問，都要提出來?；蛟S是功能點PM沒有寫清楚，或許是功能本身的不完整，或許單純地就是你不明白。需要補充的讓PM補充清楚，不要靠自己腦補來理解需求，大部分情況下設計師與PM理解的，都不是同一件事。
不要覺得不好意思，就不說出你的疑惑，很有可能你疑惑的地方，也會造成用戶的疑惑。不懂就問，是一件很重要的事，這會關系到后續設計稿的輸出方向以及交互說明的補充。如果你自己都不明白，你要如何確保你的設計能讓用戶明白。
如果當下你覺得PM提出的解決方案是不合理的或者有更好方案，可以直接說出來，不要埋藏在心中。說出來，大家一起討論，這就是你增加曝光的時刻。不管結果是否被采納，你都是雙贏。為什么這么說？如果被采納，這無疑是好的，可以讓你的團隊更加信賴你，如果你剛入職或者是加入一個新的項目組，這都是一個建立關系的好的表現。那如果后來證明，你的方案有問題呢。其實這也是件好事，至少可以發現在對產品理解中是存在你所不知道的gap， 所以你需要加強邏輯的嚴謹性和對產品的理解。
2. 記下你覺得有疑問的地方，但是一時說不清楚
我不知道你有沒有碰到過，你覺得這個需求有點怪，有點不符合用戶的使用習慣，或者你覺得PM的解決方案讓你覺得就是有不妥，但是當下你無法講清楚，也沒有更好的方案
如果是這種情況，我建議先等等。你可以等會議結束，自己再梳理一遍，不懂再問下PM，把需求理清楚。有時候出現這種問題，不一定是PM的問題，可能是對需求的理解錯了，或者你根本不理解他在說什么。
對于不懂的是要提出來，但是如果你自己也講不清楚你不清楚的到底是什么問題，那就先不要問。我想問一個問題前，你要先能清晰的表述這個問題。
3. 不要輕易打斷PM的需求講解
會議中，可能會比較尷尬的碰到一種情況，就是一聽到不懂的，馬上反饋要PM解釋，但是可能他正要講或者他稍后會講清楚。但是你不恰當的問題則會打斷他的思路，也同樣打斷其他人的思路。
所以，強烈建議在PM講完一個需求后，再提出你的疑問。
4. 需求文檔不完整的，要讓PM補充清楚
我相信大部分PM都會提供比較完整的需求文檔，但是也無法完全避免會有缺胳膊少腿的文檔。比如狀態的枚舉是不完整的，沒有考慮到異常情況，權限問題等等，這都需要PM補充完整，因為這些都會關系到你的交互說明要如何寫清楚，也避免開發同學到最后開發時，還要和PM確認有哪些狀態。
需求文檔寫清楚，是一件很重要的事情。雖然大部分情況下，我們都相信，我們能記住，但是事實上我們都會忘記，而且這樣也方便后期回溯和復盤。所以，請拒絕PM簡單粗暴的需求文檔。如果是需求的內容就應該寫在文檔里，已經砍掉的功能就不要寫在文檔里，避免文檔過于臃腫，也會造成誤解。
需求文檔至少要寫清楚需求背景、目標人群、使用場景、要解決的問題是什么以及解決方案。
既然做需求，就要清清楚楚，明明白白，杜絕糊里糊涂接需求。
5. 清楚需求計劃，需求排期
需求評審的最后，要清楚PM對這個的需求的排期是怎么安排。而且你要對照你手上其他需求的排期，要做輕重緩急的權衡。如果是需要調整的需求，則需要與需求的業務方說好。
時間很重要，要確定你真的可以在這個時間點內完成。
要確認需求的優先級是什么，是不是在這期的迭代全部完成。對于比較重工作量的需求，很有可能會分批進行，所以也要清楚第一期是設計哪些頁面。而那些會歸納在第二期、第三期的可以先放放。后面是否需求有變動，都是不可預知的，要把精力放在這期要做的需求上面。
03 需求評審后：需要確認的事
1. 重新梳理需求
需求評審時，是PM按他的理解在講解需求。所以評審結束后，設計師要按自己的理解重新梳理一遍，方法不限，可以是畫草圖，可以是用思維腦圖，主要是讓你真的理解需求，而不是一知半懂。
其實評審時，要完全理解需求，還是有一定難度的，因為你的思路基本上都是跟著PM走，有時候好像當下理解了，但是自己梳理時，又發現新的問題，這其實也是正常的，可以和PM再約下時間，對下需求。
2. 需求，是否真的需要設計師介入
這個問題是不是很奇怪。但是在眾多的需求中，有一些需求其實在前期不一定要設計師來介入。比如一個不是很完整的產品，功能大部分都沒確定，前期可能就一兩個頁面。而這個頁面可能就是一個列表，一個詳情頁，這樣的頁面，前端完全可以自己搭建起來。設計師可以等產品功能更加完整了再介入設計，至少是一個產品，而不是一兩個頁面。
設計師也需要優化資源，投入到更需要設計的產品當中。當然如果公司本身也沒什么產品，你也很閑，和PM關系也很和諧，也不會占你太多時間，你也可以不考慮這個問題，哈哈。
最后的話
對于需求評審，有些設計師總是有莫名的抗拒，不是很愿意參與前期的評審，覺得PM和開發在討論的事情，自己也聽不懂，在會議里面就是從頭坐到尾，挺無聊的。還不如討論完，直接告訴她要改的是什么。如果你是初級設計師，這屬于可以理解的范圍，但是如果你想往上發展，你就要往前走。
其實不懂，說明你不夠理解產品，所以這不是他們的問題。
設計師要參加評審會其中一個原因是，你可以在設計前就干掉那些不需要做的需求。有時候有些需求，不一定要靠設計解決，也可以完全靠技術手段解決。
比如因為某些不可說明的技術原因，在頁面上要放一個很突兀的刷新按鈕，讓用戶手動刷新頁面，但其實對用戶來說，是多做一步。那為什么會產生這個的需求的原因可能是，這個數據不是當前平臺的，是從第三方平臺獲取過來的，而第三方平臺因為某些原因無法與當前平臺做到數據實時互通。而類似這種問題，其實就要考慮開發同學用技術去解決，而不是把問題留給用戶。
需求評審，其實不可怕，真的。
本文由@箴鹽設計? 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
