起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求評審會：一個神奇的會議
文章從交互設計師的角度出發，分享了作者站在交互設計視角上面對需求評審會議的看法。
引子
前天聽到了坐在我背后的產品小姐姐和UI小姐姐，關于某一個需求的激烈討（si）論（bi）。最后的糾結的點是：
“我在需求文檔里寫這么清楚，而且你需求評審會也沒有提出來，現在又說有問題？”
“你這個文檔本來就沒寫清楚，而且會上那么短時間不可能發現這些細節問題，總要要具體設 ? ?計過程中才會發現。”
突然覺得，需求評審會是個很神奇的會議。
情況大概就是：
交互設計師：你這個業務邏輯有問題吧，少了這樣，這樣還有這樣的情況，體驗太差了。
UI設計：為什么頁面結構這么復雜，跟我們目前根本不是一個風格的東西。
開發：你確定要這么做？開發難度很高啊，周期可能會很長！
運營/市場：你這樣的目的是什么？你確定用戶會喜歡？我覺得沒有賣點啊。
然后就需要產品經理一個個耐心的解釋需求，然后耐性消失開始賣萌耍賤，直到被逼死后大家勉強達成共識！
由于本人是一名交互設計師，就談談交互設計師對需求評審會的一些想法。
會前準備
1、盡可能充分的理解需求
一般在需求評審會之前，產品經理會提前將需求文檔發送到各個崗位手里，那么交互設計師其實從這個時候，工作就已經開始了，產品經理提供的產品需求說明文檔，是交互設計師開展交互設計的主要依據。因為最后的交互方案肯定是需要滿足需求文檔里的所有功能的。
所以要盡可能的去理解產品的背景、業務、設計初衷等信息，這會幫你奠定之后的交互風格。
2、整理出自己需要的需求功能列表
交互設計師在了解了需求的背景目的以后，要著手對需求文檔進行拆解和梳理，梳理的目的在于去掉文檔中多余信息，將交互相關的羅列出來，通過XMind、腦圖等思維導圖工具進行分類整理，形成比較直觀的功能列表。
3、整理成多維度的需求
對于整理出來的功能列表，更多的是構思中的產品架構，是思維上的，對設計師來說，并不能直接使用。因此，交互設計需要對功能列表進一步的加工，打破功能縱向上的聯系，完成功能橫向上的關聯。
簡單來說，就是將各個獨立功能需求進行連接。將零散的需求能夠成為一個整體。
以上說的可能比較抽象，我們看一個案例：
需求：開發一個餐廳的點餐系統。
我們將需求套用至上面的三個步驟中：
步驟1 ? 盡可能充分的理解需求
這部分工作，就是在會前，我們應該充分的去了解需求的背景等相關信息。
比如：
餐廳為什么需要打破原來的點餐規則，因為工作效率？互聯網+的噱頭？還是有其他不可抗力的因素？
這樣的需求背景就會影響到整個系統的交互設計風格，如果是因為效率，那么你的交互更應該注重效率，把步驟盡量簡化，如果是因為蹭互聯網熱度找一些噱頭，那么你可以設計更加酷炫的交互方案，加入一些動效、過場動畫等。
步驟2 ? 整理出自己需要的需求功能列表
這部分我們需要借助一些思維導圖工具來幫助自己整理，請看下圖：
上方我們根據需求文檔對點餐系統的功能進行了整理，整理完后，可以讓你頁面布局的時候，能夠更加直觀，不會漏掉該有的功能點。
1.3 整理成多維度的需求
第三部分的內容就是把需求進行多維度的整合。還是一樣，看下圖：
當你將所有功能點用業務邏輯圖進行整理和關聯之后，你會發現，第二步驟其實還漏掉了一部分內容，那就是系統是否有庫存概念，如果沒有庫存了要怎么辦？有庫存的情況下在什么時候對庫存進行增減，是下單后？還是支付后？這些都是需求不確定的因素，也影響到你頁面之間的交互邏輯。
因此，在需求評審會議之前，對需求進行三步走的分析、拆解和整合是很重要的，如果在時間充裕的情況下，可以畫一些線框圖在需求會上進行交互大方向上的討論。
2.會議上
評審會上，首先肯定會由產品經理會對主要功能需求與特殊功能需求進行闡述，這個時候，交互設計師就要把自己所理解的需求與產品經理所描述的需求進行校對，看看其中是否能到了產品經理的預期值。對于需求有疑問的地方，在會上提出并進行探討。
上面也提到了，如果在時間充裕的情況下，可以畫出一些線框圖來進行討論。評審會的作用不僅僅是產品經理對產品功能和業務向其他人員單向輸出的過程，也是交互設計師明確需求，在腦海中把需求向界面轉化的過程。所以在這個時候，如果有一部分界面的線框圖來幫助自己闡述對產品界面交互的構思，那么對于確認最終的交互設計方向會很有幫助。
當然在這個過程中肯定會有很多建議與不同意見，這都是很正常的現象。那么就說幾點在會上討論的時候該注意的東西：
1、不要糾結于某個細節點：
會議人員多的時候，容易陷入大家集體糾結于某個細節點，比如，第三方登錄之后，是否需要另外設置昵稱？這樣的需求點并不重要，完全可以在會后直接與產品討論決定即可，在需求會上糾結于這樣權重的問題的時候，無疑是在浪費生命。
需求評審會是一場產品經理完整的描述功能需求，討論技術實現方案以及評估工期時間節點為主的一場會議。不要忘記會議初衷！
2、允許一定程度的發散：
如果同時負責兩個以上產品的時候往往會有這種情況，就是之前某個做過的產品的某些邏輯可以直接拿來復用，這個無可厚非，既節省了時間成本也節省了人工成本；但是出于業務的差異性，如果討論的過程中，突然某個人想到了之前的某個業務流的問題并發起了談論，那么暫時不要阻止，允許他有思考的時間，或許你可以在討論中發現以前沒有發現的有意思的東西，當節點到了之后，那么拉回來，繼續我們剛才沒有繼續完成的問題，繼續討論。要允許一定程度的發散。
3、切忌陷入開發討論
在評審會上，很多時候會確定技術實現方案，但是絕對還沒有涉及到具體開發細節上，這個時候陷入的開發討論很多時候都僅是開發人員出于下意識的跟產品經理抱怨開發難度過高，時間周期可能會很長。但是往往過后開發人員細想想，開發難度遠沒有想象中的復雜。
所以在會上可以討論技術實現方案，比如用源生開發、用H5套殼開發，亦或者混合開發等技術方案層面上的討論。切忌陷入開發細節的討論。
總的來說，交互設計師要在會議上確認交互界面設計方向，盡可能詳細的了解功能與業務邏輯，解答需求梳理過程中的出現的問題。
評審會后
評審會后交互設計師就開始進入交互設計的階段，但是并不建議立馬開始設計，要預留出一定量的時間對在會上新接收到的新的需求理解進行消化了整理。在充分理解需求之后才開始著手設計。
溝通很重要！
在設計過程中，如果有遇到一些模棱兩可的問題，一定要及時向相關人員再次明確。尤其是一些開發上的問題，在你不確定能不能實現的情況下（更多時候是取決于想不想實現，據說程序員世界沒有實現不了的功能），一定要找相關人員提前進行溝通，否則一旦無法實現，可能會導致整個交互方案被否定。所以，多多溝通吧。
這是我對需求評審會的一些理解與建議，希望對新人們有所幫助。
以上。
本文由 @endlishted 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
不存在，不管怎么說任何
為什么是在填完桌號后才檢查是否有庫存？
交互設計師和產品經理的區別是什么呢？
PM更注重需求的可行性，也就是需求本身，他們前期需要做大量的調研去決定某個需求是不是進入產品的迭代周期。而交互本身關心業務邏輯和用戶體驗。在產品決定需求要做的時候，不是去否定需求，而是挖掘這個需求的根源，去把需求用功能提現的更完美。
贊！
我們進行產品需求評審時，UE都已經出來了，更多的時候是UE結合PRD在那里講，感覺實際操作流程和理想的產品設計流程還是有些出入，如果只是單純的拿著需求在那里講，估計研發的同學又不高興了
是的，開發希望看著更詳細的交互稿來評審需求。所以產品經理往往考慮的很不周全就把東西丟給交互做，然后交互出了挺完整的方案后去評審，有挺大概率需要做大調整。這樣交互的工作量就大了，感覺幾乎不需要產品經理，尤其是那些沒有產品感的產品經理。這樣一來，交互設計師就要提前去跟開發接觸，探討實現能力，工作量不小啊。開發覺得光有產品文檔，后續變化空間還很大，搞不好就有坑，這個作為設計師我也可以理解，但是一定有一些基礎的東西可以先決定的，而不是把需求評審和設計評審堆在一起來解決。
哈哈，跟我現在組織需求評審的流程差不多，會上先講需求，然后美工把頁面如何設計表述一下，再和開發大致確認是否技術上有問題，沒有的話大家就稍微腦洞一下，最后全場樂呵呵地結束評審會。
這就厲害了。大家立即達成共識的那種嗎。。
有些能立刻達成，有些還是需要會后再繼續溝通確認，畢竟會也不能開太久，細節也不能討論太多。
流程圖是Axure畫的嗎？
是的，偷懶了，就AX隨意畫了一下。 ??
就作者想通過整理需求進行多維度的分析很贊賞，額，發現一個小點：1.3那張需求圖來說，判斷邏輯應該先判斷庫存，再選擇菜品參數的，覺得那張圖就有些出入
這就涉及到具體業務了，畢竟我這個案例是隨意想的，并不嚴謹。
但是我們換個角度考慮，如果是先判斷庫存的話，僅存最后一份菜品的話，客戶A先進入選擇菜品參數，導致客戶B顯示沒有庫存，但是最后客戶A放棄了沒有下單。那么菜品的庫存又變成1，結果就是客戶A和客戶B都沒有下單成功，有可能導致庫存一直變動，所以拋開具體場景，業務邏輯上來說，應該是要以下單的動作作為扣取庫存的信號是比較合理。
我們的處理邏輯：先判斷菜品庫存參數，當然下單也會再次判斷庫存