產(chǎn)品經(jīng)理參加需求評審,設(shè)計師需要注意這幾個問題

1、編輯導(dǎo)讀：需求評審會，雖然是產(chǎn)品經(jīng)理的演講會，但是與會人員卻不是只有產(chǎn)品經(jīng)理。本文作者從設(shè)計師的解讀，對設(shè)計師參加需求評審需要注意的問題進(jìn)行了梳理總結(jié)，供大家一同參考和學(xué)習(xí)。很多人把設(shè)計師的工作單純的定位為【視覺】層面的輸出，好像只要設(shè)計稿美美地就大功告成了。但是，我們都知道，其實不是這么簡單。設(shè)計師的工作職責(zé)不只在最后輸出的美觀，同樣重要的是產(chǎn)出的過程。需求的產(chǎn)生，需求的背景，需求的解決方案等等。不要讓設(shè)計是斷層的，它應(yīng)該是完整的，有開始，有結(jié)束。設(shè)計的前期， PM 一般會拉個需求評審會，這時設(shè)計師也需要參與到其中，不要等到需求完全確定了，設(shè)計才開始介入。有些不合理的需求，應(yīng)該從一開始就規(guī)避

2、。如果PM 沒有這個習(xí)慣，你可以溫柔地建議他拉你一起。設(shè)計師要在產(chǎn)品的開始和結(jié)束都滲透在其中，這樣你才能對一個產(chǎn)品整體性更清楚，也更有把握。需求評審是一件比較費力費時的事情，所以在確定需求評審時間后，可以先請 PM 給你一份需求文檔，可以先簡單的了解，對于不理解的概念，可以提前自己弄清楚，這樣也可以避免在評審會中提出太過初級的問題。如果是對現(xiàn)有產(chǎn)品的改版，可以先了解產(chǎn)品線上頁面是怎么樣的，這樣也可以更了解需求，也對 PM 提出的解決方案是否真的解決用戶的問題，有進(jìn)一步的了解。我想，這樣的準(zhǔn)備工作是需要的，不要一臉茫然的參加評審會，你不需要完全明白，但是至少你要大概了解評審會要評審什么內(nèi)容。這樣

3、大家在聊需求時，你也快速接上他們的頻率，不要讓他們覺得你什么都不懂，也給不出什么建議，也不提出任何疑問，你只是角落里那個 “安靜的美男子”，這樣你就變成可有可無的角色了。我們都在談 “設(shè)計師如何掌握話語權(quán) ” ，我想提前了解產(chǎn)品需求會是重要的一步。天下武功唯快不破，設(shè)計亦然，當(dāng)你比別人快一步時，被動轉(zhuǎn)主動時，就是改變的開始。這是一個好的開始，也是與PM 、開發(fā)們建立關(guān)系的開始，當(dāng)你慢慢用自己的主動和設(shè)計能力建立彼此的信任時，他們會愿意來咨詢你的意見，而不是只當(dāng)你是一畫圖的，而這時就是你發(fā)揮你設(shè)計影響力的時候了。還有一點，提前預(yù)備你的時間，檢查你的行程表，避免會議沖突。需求評審的初審到確定方案，

4、可能需要2-3輪評審討論。在這當(dāng)中，如果你有什么疑問，都要提出來。或許是功能點PM 沒有寫清楚，或許是功能本身的不完整，或許單純地就是你不明白。需要補充的讓PM 補充清楚，不要靠自己腦補來理解需求，大部分情況下設(shè)計師與PM理解的，都不是同一件事。不要覺得不好意思，就不說出你的疑惑，很有可能你疑惑的地方，也會造成用戶的疑惑。不懂就問，是一件很重要的事，這會關(guān)系到后續(xù)設(shè)計稿的輸出方向以及交互說明的補充。如果你自己都不明白，你要如何確保你的設(shè)計能讓用戶明白。如果當(dāng)下你覺得 PM 提出的解決方案是不合理的或者有更好方案，可以直接說出來，不要埋藏在心中。說出來，大家一起討論，這就是你增加曝光的時刻。不管

5、結(jié)果是否被采納，你都是雙贏。為什么這么說？如果被采納，這無疑是好的，可以讓你的團(tuán)隊更加信賴你，如果你剛?cè)肼毣蛘呤羌尤胍粋€新的項目組，這都是一個建立關(guān)系的好的表現(xiàn)。那如果后來證明，你的方案有問題呢。其實這也是件好事，至少可以發(fā)現(xiàn)在對產(chǎn)品理解中是存在你所不知道的gap，所以你需要加強邏輯的嚴(yán)謹(jǐn)性和對產(chǎn)品的理解。我不知道你有沒有碰到過，你覺得這個需求有點怪，有點不符合用戶的使用習(xí)慣，或者你覺得PM 的解決方案讓你覺得就是有不妥，但是當(dāng)下你無法講清楚，也沒有更好的方案如果是這種情況，我建議先等等。你可以等會議結(jié)束，自己再梳理一遍，不懂再問下PM,把需求理清楚。有時候出現(xiàn)這種問題，不一定是PM的問題,可

6、能是對需求的理解錯了，或者你根本不理解他在說什么。對于不懂的是要提出來，但是如果你自己也講不清楚你不清楚的到底是什么問題，那就先不要問。我想問一個問題前，你要先能清晰的表述這個問題。會議中，可能會比較尷尬的碰到一種情況，就是一聽到不懂的，馬上反饋要 PM 解釋，但是可能他正要講或者他稍后會講清楚。但是你不恰當(dāng)?shù)膯栴}則會打斷他的思路，也同樣打斷其他人的思路。所以，強烈建議在 PM 講完一個需求后，再提出你的疑問。我相信大部分PM 都會提供比較完整的需求文檔，但是也無法完全避免會有缺胳膊少腿的文檔。比如狀態(tài)的枚舉是不完整的，沒有考慮到異常情況，權(quán)限問題等等，這都需要PM 補充完整，因為這些都會關(guān)系

7、到你的交互說明要如何寫清楚，也避免開發(fā)同學(xué)到最后開發(fā)時，還要和 PM 確認(rèn)有哪些狀態(tài)。需求文檔寫清楚，是一件很重要的事情。雖然大部分情況下，我們都相信，我們能記住，但是事實上我們都會忘記，而且這樣也方便后期回溯和復(fù)盤。所以，請拒絕PM 簡單粗暴的需求文檔。如果是需求的內(nèi)容就應(yīng)該寫在文檔里，已經(jīng)砍掉的功能就不要寫在文檔里，避免文檔過于臃腫，也會造成誤解。需求文檔至少要寫清楚需求背景、目標(biāo)人群、使用場景、要解決的問題是什么以及解決方案。既然做需求，就要清清楚楚，明明白白，杜絕糊里糊涂接需求。需求評審的最后，要清楚PM 對這個的需求的排期是怎么安排。而且你要對照你手上其他需求的排期，要做輕重緩急的權(quán)

8、衡。如果是需要調(diào)整的需求，則需要與需求的業(yè)務(wù)方說好。時間很重要，要確定你真的可以在這個時間點內(nèi)完成。要確認(rèn)需求的優(yōu)先級是什么，是不是在這期的迭代全部完成。對于比較重工作量的需求，很有可能會分批進(jìn)行，所以也要清楚第一期是設(shè)計哪些頁面。而那些會歸納在第二期、第三期的可以先放放。后面是否需求有變動，都是不可預(yù)知的，要把精力放在這期要做的需求上面。需求評審時，是PM 按他的理解在講解需求。所以評審結(jié)束后，設(shè)計師要按自己的理解重新梳理一遍，方法不限，可以是畫草圖，可以是用思維腦圖，主要是讓你真的理解需求，而不是一知半懂。其實評審時，要完全理解需求，還是有一定難度的，因為你的思路基本上都是跟著 PM 走，

9、有時候好像當(dāng)下理解了，但是自己梳理時，又發(fā)現(xiàn)新的問題，這其實也是正常的，可以和 PM 再約下時間，對下需求。這個問題是不是很奇怪。但是在眾多的需求中，有一些需求其實在前期不一定要設(shè)計師來介入。比如一個不是很完整的產(chǎn)品，功能大部分都沒確定，前期可能就一兩個頁面。而這個頁面可能就是一個列表，一個詳情頁，這樣的頁面，前端完全可以自己搭建起來。設(shè)計師可以等產(chǎn)品功能更加完整了再介入設(shè)計，至少是一個產(chǎn)品，而不是一兩個頁面。設(shè)計師也需要優(yōu)化資源，投入到更需要設(shè)計的產(chǎn)品當(dāng)中。當(dāng)然如果公司本身也沒什么產(chǎn)品，你也很閑，和 PM 關(guān)系也很和諧，也不會占你太多時間，你也可以不考慮這個問題，哈哈。對于需求評審，有些設(shè)計師總是有莫名的抗拒，不是很愿意參與前期的評審，覺得 PM 和開發(fā)在討論的事情，自己也聽不懂，在會議里面就是從頭坐到尾，挺無聊的。還不如討論完，