會議對交互設計師來說是家常便飯了，忙起來的時候甚至成為負擔。最近總結了幾點關于開會的經驗。
首先直接上幾條簡單粗暴的小經驗：
- 拒絕不必要的會議；
- 與你相關的部分結束后可以先行離開；
- 合理安排會議時間；
- 會議過程中適當進行引導和控場。
一、明確會議的主題和目的
如果你是主持人，可以在會議邀請、會議開始時將主題告知全體參與者。比如在邀請郵件的標題上用一句話說明會議主題，在正文中列出這次會議的子主題（如有），在會議開始時，再次向參與者闡述下主題和背景。會議中途，時刻地牢記主題，當討論偏離主題時，及時打斷和引導。會議結束時，再次向全體成員匯報會議總結，整理和周知會議紀要。
如果你是普通參與者，也可以在會議前先圍繞主題進行思考，并準備相關資料，在闡述與討論時，要不斷提醒自己不要脫離主題。
二、會議定位
是評審，還是頭腦風暴，還是分享會。每一種定位可能有不同的會議形式，比如頭腦風暴需要大家先散發再收斂，而不是立即對某個人的方案進行詳細評估。如果是分享會，則不對案例中的方案進行細節的評價，而更鼓勵大家回憶自己過去的經驗或者對未來的展望和總結。
三、需求溝通
最后再說一點關于需求溝通的，有些會議中，很多人在扯皮，尤其是中層身份（相對于當時其他與會者）的人，在遇到真正棘手的問題時，他們本能地逃避思考，然后來回重復概念性的東西，比如“總之肯定要簡單”、“要從用戶的角度出發”這種高大上的廢話。本質上，他們在無意識地逃避真正棘手的問題。因此，作為設計師，我們需要引導他說出真正需求，比如讓他們描繪自己的期望，然后你邊聽邊分析他為什么會有這樣的期望，如果你分析不出或不確定，直接問他們，切忌不能因為要面子而不好意思追問。那么，下一個問題就是，如何確定你是否真正理解了呢？我們容易犯一個錯誤，在聽完別人描述后，以為自己懂了，但實際上未必，然后兩個人信息理解偏差越來越大，最要命的是，他也以為你懂了，等你交付時才發現原來你根本沒理解。這個時候，我最常用的方法是，傾聽一段描述后，向他們反饋你的理解，比如“是不是這個意思：xxxxx”。這樣是為了保證對話者之間信息理解同步，以便于繼續前進。當然，需求溝通本身也是個大話題，下次可以單獨再總結歸納一下。
