很多人把設(shè)計師的工作單純的定位為「視覺」層面的輸出，好像只要設(shè)計稿美美地就大功告成了。但是，我們都知道，其實(shí)不是這么簡單。

設(shè)計師的工作職責(zé)不只在最后輸出的美觀，同樣重要的是產(chǎn)出的過程。需求的產(chǎn)生，需求的背景，需求的解決方案等等。不要讓設(shè)計是斷層的，它應(yīng)該是完整的，有開始，有結(jié)束。

需求評審前，你不可遺漏的準(zhǔn)備工作

設(shè)計的前期，PM一般會拉個需求評審會，這時設(shè)計師也需要參與到其中，不要等到需求完全確定了，設(shè)計才開始介入。有些不合理的需求，應(yīng)該從一開始就規(guī)避。如果PM沒有這個習(xí)慣，你可以溫柔地建議他拉你一起。設(shè)計師要在產(chǎn)品的開始和結(jié)束都滲透在其中，這樣你才能對一個產(chǎn)品整體性更清楚，也更有把握。

需求評審是一件比較費(fèi)力費(fèi)時的事情，所以在確定需求評審時間后，可以先請PM給你一份需求文檔，可以先簡單的了解，對于不理解的概念，可以提前自己弄清楚，這樣也可以避免在評審會中提出太過初級的問題。如果是對現(xiàn)有產(chǎn)品的改版，可以先了解產(chǎn)品線上頁面是怎么樣的，這樣也可以更了解需求，也對PM提出的解決方案是否真的解決用戶的問題，有進(jìn)一步的了解。

我想，這樣的準(zhǔn)備工作是需要的，不要一臉茫然的參加評審會，你不需要完全明白，但是至少你要大概了解評審會要評審什么內(nèi)容。這樣大家在聊需求時，你也快速接上他們的頻率，不要讓他們覺得你什么都不懂，也給不出什么建議，也不提出任何疑問，你只是角落里那個「安靜的美男子」，這樣你就變成可有可無的角色了。

我們都在談「設(shè)計師如何掌握話語權(quán)」，我想提前了解產(chǎn)品需求會是重要的一步。天下武功唯快不破，設(shè)計亦然，當(dāng)你比別人快一步時，被動轉(zhuǎn)主動時，就是改變的開始。這是一個好的開始，也是與PM、開發(fā)們建立關(guān)系的開始，當(dāng)你慢慢用自己的主動和設(shè)計能力建立彼此的信任時，他們會愿意來咨詢你的意見，而不是只當(dāng)你是一畫圖的，而這時就是你發(fā)揮你設(shè)計影響力的時候了。

還有一點(diǎn)，提前預(yù)備你的時間，檢查你的行程表，避免會議沖突。

需求評審中：你要做的事

1. 勇敢提出你的問題

需求評審的初審到確定方案，可能需要2-3輪評審討論。在這當(dāng)中，如果你有什么疑問，都要提出來。或許是功能點(diǎn)PM沒有寫清楚，或許是功能本身的不完整，或許單純地就是你不明白。需要補(bǔ)充的讓PM補(bǔ)充清楚，不要靠自己腦補(bǔ)來理解需求，大部分情況下設(shè)計師與PM理解的，都不是同一件事。

不要覺得不好意思，就不說出你的疑惑，很有可能你疑惑的地方，也會造成用戶的疑惑。不懂就問，是一件很重要的事，這會關(guān)系到后續(xù)設(shè)計稿的輸出方向以及交互說明的補(bǔ)充。如果你自己都不明白，你要如何確保你的設(shè)計能讓用戶明白。

如果當(dāng)下你覺得PM提出的解決方案是不合理的或者有更好方案，可以直接說出來，不要埋藏在心中。說出來，大家一起討論，這就是你增加曝光的時刻。不管結(jié)果是否被采納，你都是雙贏。為什么這么說？如果被采納，這無疑是好的，可以讓你的團(tuán)隊更加信賴你，如果你剛?cè)肼毣蛘呤羌尤胍粋€新的項目組，這都是一個建立關(guān)系的好的表現(xiàn)。那如果后來證明，你的方案有問題呢。其實(shí)這也是件好事，至少可以發(fā)現(xiàn)在對產(chǎn)品理解中是存在你所不知道的gap， 所以你需要加強(qiáng)邏輯的嚴(yán)謹(jǐn)性和對產(chǎn)品的理解。

2. 記下你覺得有疑問的地方，但是一時說不清楚

我不知道你有沒有碰到過，你覺得這個需求有點(diǎn)怪，有點(diǎn)不符合用戶的使用習(xí)慣，或者你覺得PM的解決方案讓你覺得就是有不妥，但是當(dāng)下你無法講清楚，也沒有更好的方案

如果是這種情況，我建議先等等。你可以等會議結(jié)束，自己再梳理一遍，不懂再問下PM，把需求理清楚。有時候出現(xiàn)這種問題，不一定是PM的問題，可能是對需求的理解錯了，或者你根本不理解他在說什么。

對于不懂的是要提出來，但是如果你自己也講不清楚你不清楚的到底是什么問題，那就先不要問。我想問一個問題前，你要先能清晰的表述這個問題。

3. 不要輕易打斷PM的需求講解

會議中，可能會比較尷尬的碰到一種情況，就是一聽到不懂的，馬上反饋要PM解釋，但是可能他正要講或者他稍后會講清楚。但是你不恰當(dāng)?shù)膯栴}則會打斷他的思路，也同樣打斷其他人的思路。

所以，強(qiáng)烈建議在PM講完一個需求后，再提出你的疑問。

4. 需求文檔不完整的，要讓PM補(bǔ)充清楚

我相信大部分PM都會提供比較完整的需求文檔，但是也無法完全避免會有缺胳膊少腿的文檔。比如狀態(tài)的枚舉是不完整的，沒有考慮到異常情況，權(quán)限問題等等，這都需要PM補(bǔ)充完整，因為這些都會關(guān)系到你的交互說明要如何寫清楚，也避免開發(fā)同學(xué)到最后開發(fā)時，還要和PM確認(rèn)有哪些狀態(tài)。

需求文檔寫清楚，是一件很重要的事情。雖然大部分情況下，我們都相信，我們能記住，但是事實(shí)上我們都會忘記，而且這樣也方便后期回溯和復(fù)盤。所以，請拒絕PM簡單粗暴的需求文檔。如果是需求的內(nèi)容就應(yīng)該寫在文檔里，已經(jīng)砍掉的功能就不要寫在文檔里，避免文檔過于臃腫，也會造成誤解。

需求文檔至少要寫清楚需求背景、目標(biāo)人群、使用場景、要解決的問題是什么以及解決方案。

既然做需求，就要清清楚楚，明明白白，杜絕糊里糊涂接需求。

5. 清楚需求計劃，需求排期

需求評審的最后，要清楚PM對這個的需求的排期是怎么安排。而且你要對照你手上其他需求的排期，要做輕重緩急的權(quán)衡。如果是需要調(diào)整的需求，則需要與需求的業(yè)務(wù)方說好。

時間很重要，要確定你真的可以在這個時間點(diǎn)內(nèi)完成。

要確認(rèn)需求的優(yōu)先級是什么，是不是在這期的迭代全部完成。對于比較重工作量的需求，很有可能會分批進(jìn)行，所以也要清楚第一期是設(shè)計哪些頁面。而那些會歸納在第二期、第三期的可以先放放。后面是否需求有變動，都是不可預(yù)知的，要把精力放在這期要做的需求上面。

需求評審后：需要確認(rèn)的事

1. 重新梳理需求

需求評審時，是PM按他的理解在講解需求。所以評審結(jié)束后，設(shè)計師要按自己的理解重新梳理一遍，方法不限，可以是畫草圖，可以是用思維腦圖，主要是讓你真的理解需求，而不是一知半懂。

其實(shí)評審時，要完全理解需求，還是有一定難度的，因為你的思路基本上都是跟著PM走，有時候好像當(dāng)下理解了，但是自己梳理時，又發(fā)現(xiàn)新的問題，這其實(shí)也是正常的，可以和PM再約下時間，對下需求。

2. 需求，是否真的需要設(shè)計師介入

這個問題是不是很奇怪。但是在眾多的需求中，有一些需求其實(shí)在前期不一定要設(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ā)在討論的事情，自己也聽不懂，在會議里面就是從頭坐到尾，挺無聊的。還不如討論完，直接告訴她要改的是什么。如果你是初級設(shè)計師，這屬于可以理解的范圍，但是如果你想往上發(fā)展，你就要往前走。

其實(shí)不懂，說明你不夠理解產(chǎn)品，所以這不是他們的問題。

設(shè)計師要參加評審會其中一個原因是，你可以在設(shè)計前就干掉那些不需要做的需求。有時候有些需求，不一定要靠設(shè)計解決，也可以完全靠技術(shù)手段解決。

比如因為某些不可說明的技術(shù)原因，在頁面上要放一個很突兀的刷新按鈕，讓用戶手動刷新頁面，但其實(shí)對用戶來說，是多做一步。那為什么會產(chǎn)生這個的需求的原因可能是，這個數(shù)據(jù)不是當(dāng)前平臺的，是從第三方平臺獲取過來的，而第三方平臺因為某些原因無法與當(dāng)前平臺做到數(shù)據(jù)實(shí)時互通。而類似這種問題，其實(shí)就要考慮開發(fā)同學(xué)用技術(shù)去解決，而不是把問題留給用戶。

需求評審，其實(shí)不可怕，真的。

更多需求評審干貨：

歡迎關(guān)注作者微信公眾號：「箴鹽設(shè)計」