需求評審會：一個神奇的會議

引子

前天聽到了坐在我背後的產品小姐姐和UI小姐姐，關於某一個需求的激烈討（si）論（bi）。最後的糾結的點是：

「我在需求文檔里寫這麼清楚，而且你需求評審會也沒有提出來，現在又說有問題？」 「你這個文檔本來就沒寫清楚，而且會上那麼短時間不可能發現這些細節問題，總要要具體設 計過程中才會發現。」

突然覺得，需求評審會是個很神奇的會議。

情況大概就是：

交互設計師：你這個業務邏輯有問題吧，少了這樣，這樣還有這樣的情況，體驗太差了。

UI設計：為什麼頁面結構這麼複雜，跟我們目前根本不是一個風格的東西。

開發：你確定要這麼做？開發難度很高啊，周期可能會很長！

運營/市場：你這樣的目的是什麼？你確定用戶會喜歡？我覺得沒有賣點啊。

然後就需要產品經理一個個耐心的解釋需求，然後耐性消失開始賣萌耍賤，直到被逼死後大家勉強達成共識！

由於本人是一名交互設計師，就談談交互設計師對需求評審會的一些想法。

一般在需求評審會之前，產品經理會提前將需求文檔發送到各個崗位手裡，那麼交互設計師其實從這個時候，工作就已經開始了，產品經理提供的產品需求說明文檔，是交互設計師開展交互設計的主要依據。因為最後的交互方案肯定是需要滿足需求文檔里的所有功能的。

所以要儘可能的去理解產品的背景、業務、設計初衷等信息，這會幫你奠定之後的交互風格。

交互設計師在了解了需求的背景目的以後，要著手對需求文檔進行拆解和梳理，梳理的目的在於去掉文檔中多餘信息，將交互相關的羅列出來，通過XMind、腦圖等思維導圖工具進行分類整理，形成比較直觀的功能列表。

對於整理出來的功能列表，更多的是構思中的產品架構，是思維上的，對設計師來說，並不能直接使用。因此，交互設計需要對功能列表進一步的加工，打破功能縱向上的聯繫，完成功能橫向上的關聯。

簡單來說，就是將各個獨立功能需求進行連接。將零散的需求能夠成為一個整體。

以上說的可能比較抽象，我們看一個案例：

需求：開發一個餐廳的點餐系統。

我們將需求套用至上面的三個步驟中：

步驟1 儘可能充分的理解需求

這部分工作，就是在會前，我們應該充分的去了解需求的背景等相關信息。

比如：

餐廳為什麼需要打破原來的點餐規則，因為工作效率？互聯網+的噱頭？還是有其他不可抗力的因素？

這樣的需求背景就會影響到整個系統的交互設計風格，如果是因為效率，那麼你的交互更應該注重效率，把步驟盡量簡化，如果是因為蹭互聯網熱度找一些噱頭，那麼你可以設計更加酷炫的交互方案，加入一些動效、過場動畫等。

步驟2 整理出自己需要的需求功能列表

這部分我們需要藉助一些思維導圖工具來幫助自己整理，請看下圖：

上方我們根據需求文檔對點餐系統的功能進行了整理，整理完後，可以讓你頁面布局的時候，能夠更加直觀，不會漏掉該有的功能點。

1.3 整理成多維度的需求

第三部分的內容就是把需求進行多維度的整合。還是一樣，看下圖：

當你將所有功能點用業務邏輯圖進行整理和關聯之後，你會發現，第二步驟其實還漏掉了一部分內容，那就是系統是否有庫存概念，如果沒有庫存了要怎麼辦？有庫存的情況下在什麼時候對庫存進行增減，是下單後？還是支付後？這些都是需求不確定的因素，也影響到你頁面之間的交互邏輯。

因此，在需求評審會議之前，對需求進行三步走的分析、拆解和整合是很重要的，如果在時間充裕的情況下，可以畫一些線框圖在需求會上進行交互大方向上的討論。

評審會上，首先肯定會由產品經理會對主要功能需求與特殊功能需求進行闡述，這個時候，交互設計師就要把自己所理解的需求與產品經理所描述的需求進行校對，看看其中是否能到了產品經理的預期值。對於需求有疑問的地方，在會上提出並進行探討。

上面也提到了，如果在時間充裕的情況下，可以畫出一些線框圖來進行討論。評審會的作用不僅僅是產品經理對產品功能和業務向其他人員單向輸出的過程，也是交互設計師明確需求，在腦海中把需求向界面轉化的過程。所以在這個時候，如果有一部分界面的線框圖來幫助自己闡述對產品界面交互的構思，那麼對於確認最終的交互設計方向會很有幫助。

當然在這個過程中肯定會有很多建議與不同意見，這都是很正常的現象。那麼就說幾點在會上討論的時候該注意的東西：

會議人員多的時候，容易陷入大家集體糾結於某個細節點，比如，第三方登錄之後，是否需要另外設置昵稱？這樣的需求點並不重要，完全可以在會後直接與產品討論決定即可，在需求會上糾結於這樣權重的問題的時候，無疑是在浪費生命。

需求評審會是一場產品經理完整的描述功能需求，討論技術實現方案以及評估工期時間節點為主的一場會議。不要忘記會議初衷！

2、允許一定程度的發散：

如果同時負責兩個以上產品的時候往往會有這種情況，就是之前某個做過的產品的某些邏輯可以直接拿來複用，這個無可厚非，既節省了時間成本也節省了人工成本；但是出於業務的差異性，如果討論的過程中，突然某個人想到了之前的某個業務流的問題並發起了談論，那麼暫時不要阻止，允許他有思考的時間，或許你可以在討論中發現以前沒有發現的有意思的東西，當節點到了之後，那麼拉回來，繼續我們剛才沒有繼續完成的問題，繼續討論。要允許一定程度的發散。

在評審會上，很多時候會確定技術實現方案，但是絕對還沒有涉及到具體開發細節上，這個時候陷入的開發討論很多時候都僅是開發人員出於下意識的跟產品經理抱怨開發難度過高，時間周期可能會很長。但是往往過後開發人員細想想，開發難度遠沒有想像中的複雜。

所以在會上可以討論技術實現方案，比如用源生開發、用H5套殼開發，亦或者混合開發等技術方案層面上的討論。切忌陷入開發細節的討論。

總的來說，交互設計師要在會議上確認交互界面設計方向，儘可能詳細的了解功能與業務邏輯，解答需求梳理過程中的出現的問題。

評審會後交互設計師就開始進入交互設計的階段，但是並不建議立馬開始設計，要預留出一定量的時間對在會上新接收到的新的需求理解進行消化了整理。在充分理解需求之後才開始著手設計。 溝通很重要！

在設計過程中，如果有遇到一些模稜兩可的問題，一定要及時向相關人員再次明確。尤其是一些開發上的問題，在你不確定能不能實現的情況下（更多時候是取決於想不想實現，據說程序員世界沒有實現不了的功能），一定要找相關人員提前進行溝通，否則一旦無法實現，可能會導致整個交互方案被否定。所以，多多溝通吧。

這是我對需求評審會的一些理解與建議，希望對新人們有所幫助。

以上。

本文由 @endlishted 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議

推薦閱讀：