交互設計是從得到需求開始的(以產品為主導的公司，交互設計師會參與產品需求與定位，不在本文的討論範圍之內)，一般會在獲得需求文檔以後，進行一次需求溝通（需求評審）。

需求評審會是交互稿完成之前，最為重要、參與成員最多的一次會議。由產品經理介紹相應的產品功能背景，與交互設計、視覺設計、前後端開發探討產品功能的實現邏輯與可行性方案，從中選出一個在整體效果上最優的方案。同時，與會人員給出產品在各階段的開發時間節點，便於項目經理對產品開發進度的把控。

需求評審是交互設計師通盤了解產品需求、確定功能交互方案的最佳時機。雖然後續還可以進行溝通，但是，在效率以及需求的全面性上都大打折扣，更多的是單個功能邏輯的溝通。因此，面對需求評審會，一定要做好準備，帶上腦袋去參加需求評審會，得到自己想要的東西。

首先 會前準備

一般情況下，需求評審會之前都會將需求發出來，作為接下來各階段工作的依據與目標。作為交互設計師，在拿到需求以後，工作已經開始，而不是等到需求評審以後，時間節點確定以後。在需求評審之前，有幾點工作要完成：

充分的需求理解分析

產品經理提供的產品需求說明文檔，是交互設計師開展交互設計的主要依據。最終，交互設計師設計方案要滿文檔中關於界面交互的所有功能需求。產品需求說明文檔應該包括如下內容（後期對產品需求說明文檔詳細闡述）：

對於交互設計師，主要關注的是需求詳細描述中的功能需求部分，對於功能需求的理解關鍵在於對功能的整體流程的了解與梳理。每一個產品都有若干功能組成，設計師要模擬用戶的使用場景，在使用該功能時，思考頁面應該給出的反饋與提示，來保障功能交互的順利進行，用戶目標的順利實現。

有目的的需求梳理

設計師在需求了解以後，就要對需求進行梳理，梳理的目的在於簡化功能流程，將用戶與界面之間的交互點提煉出來，梳理出相關功能任務的交互流程，可以參考《不得不懂的交互設計三要素之貳——交互流程設計》。

將文檔中出現的與界面有關的功能全部整理出來，並根據功能進行分類，完成功能聚類。然後，使用思維導圖工具XMind或者MindManager將其整理出直觀的功能列表。

整理出交互設計可用的需求

對於整理出來的功能列表，更多的是構思中的產品架構，是思維上的，對設計師來說，並不能直接使用。因此，交互設計需要對功能列表進一步的加工，打破功能縱向上的聯繫，完成功能橫向上的重構，可參考《不得不懂的交互設計三要素之壹——信息架構》。整理結果如圖（請忽略詳細功能描述）：

功能列表更多的是縱向上的功能流程，而在這一步要完成業務需求上的橫向布局。可以將各個功能分門別類的放置到相應的標籤下面，過程中也可以對具體功能進行拆分。有些功能流程會橫跨多個界面分類，將其分到不同的標籤下面，更多的考慮產品橫向的界面的關係。比如，很多Web產品的首頁是一個產品的功能概要展示，或者有一些業務目標的直接入口，用戶可以從首頁直接跳轉到其他頁面，但在功能流程上是完整流暢的。

在完成這一步以後，一個產品的具體頁面布局已經呼之欲出了。如果時間允許，或者這個列表還不夠具體，交互設計是可以將各個標籤轉換成標籤頁面，並對相應的功能進行佔位符表現，這就可以稱得上交互設計初稿。

其次 會上提問

在需求評審會上，首先，產品經理會對主要功能需求與特殊功能需求進行闡述，這個過程中，交互設計師就要對自己理解的需求進行檢測，是否符合產品經理的功能預期。對於有疑問的地方，可以進行詢問探討，直到明確為止。

需求評審會不僅僅是對產品功能，業務流程的通盤了解，也是交互設計師確認功能需求向交互界面轉化的契機。交互設計師要在會議上闡述自己的交互界面構思，解決功能疑惑，確認交互設計方向。

接下來就需要交互設計師將整理出來的、可視化的功能需求列表或者交互設計初稿展示給大家，徵求其他成員的意見，這種功能分類與頁面布局是否符合業務邏輯，可以進行適當的功能布局調整，滿產品需求。

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

最後 會議紀要

評審會結束以後，要儘快將會上得到的內容總結出來，並以郵件形式發給參會人員，特別是產品經理。一方面，防止會上確認的內容被遺忘，也便於後期在製作交互稿的時候，進行參考；另一方面，立字為證，防止需求的隨意變更。可參考《你知道交互稿完成過程中的六個要點嗎？》，文中對這方面的問題進行了詳細的闡述。

願與你同行！

敬請關注UIUX設計工作坊，微信公眾號：UIUX-HUANG，每周會有互聯網產品設計的相關文章更新，是作者的實際工作經驗，願與大家共同進步。

http://weixin.qq.com/r/ITs6IuTEo7ncraBB924z (二維碼自動識別)