現在很多企業里的“密集會議文化”使項目團隊的項目目標很難達到預期的進度要求，特別是在增強產品的用戶體驗的方面。通常來說，會議中充斥著太多的項目議程，態度不冷不熱的頭腦風暴與偏離會議的閑談，如果你在那種會議文化的環境中工作，試著用為期一天的工作坊可能是個絕佳的方式擺脫老套的會議。
在一個典型的合作團隊的環境里，對線上或者移動端產品用戶體驗的改進流程就像以下所示：
· 某人制定并安排了一個會議
· 大家在會上討論一些問題以及可能改進的方面（這些改進的方面可能又不一定和會議前準備討論的問題相關）
· 接著有些人就開始跑題并且脫離了會議開始提出的問題
· 然后大家就散了又去參加另一場會議
· 此時有人又開始安排后續會議
· 接下來在會議里老問題改頭換面繼續討論，新問題又被加了進來
上述的流程看起來就這樣無限的循環下去，導致解決的問題很少，能采取的行動就更少。假如改變這個無限循環是可以有更好的方法，但是在這為期一天的會議時間內，如果你能在全部的改進提議中提煉出的有意義的焦點，大家伙能準確定義出問題所在，頭腦風暴有能提出解決問題的方法，然后提出優先的決絕方案，也不一定讓大家參加一整天的工作坊。
然而為什么要組織大家參加工作坊？
工作坊有幾點優于會議的地方：
· 良好而積極的動機
· 產生共同的目標感
· 一天內集中涵蓋了會議需要幾周或數月完成的事情
· 使得每個人都能在解決方案上參與合作
如何開展工作坊？
這里是一個基本的把為期一天的工作坊劃分為三個相等時間段的方案：
為了驗證這個方案，讓我們找一個假設性的問題——一家健康保險公司擁有一個獨立的網站，這家公司發現在在線登記的過程中出現了問題，因此公司要搞清楚如何在下一次在線登記上線之前及時做出更好的流程改進方案。
發現問題
多數的企業在正確定義那些需要解決的問題方面做得都很糟糕，常有強烈的欲望直接跳到“修復”階段，這樣做就直接導致大量的心血花在短期的改進或是解決了錯誤的問題。在這個健康保險公司的網站的案例中，建立“解決一些用戶體驗問題”工作坊是個新的開端與好的方式來證明這些真實存在的問題，獲取這些問題的途徑大概有：
· 通過收集一些呼叫中心代理人員分享的關于消費者預約中遇到各種問題的故事
· 打印通話日志、調查結果與頁面點擊流數據在一個大幅面報告上并貼在墻上
· 讓那些對這個產品不熟悉的用戶（比如你的朋友、家人、來自別的不相關部門的同事等）使用你的產品然后讓他們談談對產品的體驗
· 收集有參考性的以前關于可用性會議的視頻或可用性報告的副本
· 發現以用戶的角度的工作坊參與者在體驗網站時出現的問題（嘗試讓他們注冊自己家庭的成員）
· 采集工作坊參與人員的一些相關的傳聞軼事（例如：“我聽到人們抱怨在確認頁的時候不知道怎么再點擊下一步”）
當工作坊的參與人員產生了關于“產品為何不依據用戶習慣來設計？”產生的“怨念”與想法時，不需要花太多的時間在細節問題上（例如:'為什么不在這一塊多些留白？”或“我不喜歡綠色”），而是使用掛圖與便簽讓參與者捕捉這些“怨念”，并保證在隨后的時間里解決這些問題。一旦把這些采集到的問題制成列表，優先考慮這些問題的嚴重程度同時選擇出重要度第一和第二位的問題為工作坊的下一階段的主要關注點，問題的嚴重程度反映在設定的問題優先級與預定目標內。
頭腦風暴解決方案
頭腦風暴階段在整個工作坊部分是比較輕松的環節，參與者大多數在的思考如何解決這些問題，以下有一些關于如何讓這一階段更有效率的小貼士：
· 優先考慮并解決一兩個問題強于試圖解決所有的問題
· 把參與者分解成跨學科的小組并匯總各個小組的討論的結果
· 鼓勵每個參與人員貢獻想法，越多越好
· 推遲關于解決這些問題需要付出多少成本這類話題的討論，允許這些討論出的解決方案是耗時且高成本的，并且在理想的源配置內就能實現這個方案
· 提供草圖等的材料，鼓勵每個參與者視覺化解決方案
如果頭腦風暴會議環節開始證實了正確的方向，那么從發現問題到解決方案這條道路就會異常的順暢，但值得注意的是，在頭腦風暴環節中會出現這樣的陷阱，也就是經常會接受第一個可行性方案、發出最響亮聲音者的那個方案以及地位最高者提出的方案，可是這些往往不是最好的對問題的回答，所以分小組討論能很好的避免這一問題，同時一個好的主持人有更多的方法能保證所有的想法能得到徹底的平等對待。
按大小與優先級排列解決方案
這里有個基本的矩陣，你為了得到一個特定的方案，可以用這個矩陣來權衡對它投入的成本大小與這對這個優先級方案會產生的潛在利益，最終希望能選擇出最可能的解決方案：
例如下表中開始列出你的潛在的解決方案的矩陣列表。
工作坊中的這個階段是比較困難的，經常會在例如“我們貌似知道的方案還不夠多”這樣的疑問中停滯不前，為了更有效率的方案的大小與優先級進行權衡，有以下幾個小貼士：
· 在T恤大小的區域內對這些可能的解決方案進行影響力與投入成本大小排名（例如最大、中等、最?。?/span>
· 如果技術團隊對某一方案猛烈抨擊，那就得承認這方案的實際工作負載可能存在問題，同時得承認技術團隊以最小投入的那個方案是最可能往前推進的方案
總結你的工作坊
從定義發現的問題到列出可能新的解決方案這條路并不是一帆風順的，如果你一天內仍然沒得出集體的決定，不要灰心，這也是常事。如果你用完了規定的時間發現還是沒有任何決議產生，試著從“產生決議”轉變到再次分配任務與再進行下一個步驟。所以在工作坊的結尾，常會有很驚喜的輸出分享給大家：
· 收集了更多的問題（例如“用戶在登記的過程中在哪里流失的？”）
· 探索了替代的解決方案（例如“盡管我們最喜歡的這個提案，但是耗費資源太大，還是在下一次用戶線上登記時期之前采用更快速的改進方案可能更好”）
· 研究范圍更細致（例如“IT研發團隊在兩個備選方案中需要知道哪一個的開發成本更低”）
工作坊的基本要素
1. 哪些人來參加：最好盡可能請跨學科的人員參加，比如說，邀請話務中心代理人員、項目經理、銷售團隊的人員、設計師、文案人員以及工程師團隊人員參與工作坊來共同解決問題。
2. 關掉手機電腦設備：在開始工作坊之前確保參與人員不在發短信、收發郵件以及與本次工作坊無關的事情，如果大家不能全身心的參與，他們是根本沒必要來參加這個工作坊的。
3. 時間安排：給工作坊的尋找問題——解決方案——權衡方案三個階段各分配兩個小時的時間，還要確保安排了休息的時間；否則參與者在中途產生疲勞迷茫的狀態。所以安排他們吃東西的時間，收發郵件的時間，上洗手間的時間以及還有些閑聊的時間。同時提供零食和飲料可以有效的減少各位參與者的疲勞迷茫的狀態產生。
4.指定一個主持人：需要有個人確保所有需要的材料都準備齊整，把握工作坊的每個階段的方向與討論的目的，確保遵守時間限制，及時的記錄在白板上的信息。幾乎任何一個參與者都能扮演主持人身份，但是一個有經驗的主持人能讓工作坊更有效率，尤其是有些事情沒再往前推薦的時候重新定義方向的能力，霸氣的管理風格，又能保證能夠達到設定的目標。如果你沒有機會從外部找到一個主持人，自告奮勇你自己做這個主持人身份并推動整個工作坊往前進。
5. 克服第一次的緊張感：如果你是第一次開展工作坊又很在意成功與否，其實只要能在這一天中專注于你設定的那個清晰明確的目標（例如，為在線登記系統指定一個可行性的改進方案）與制定完備的活動議程，你可以從參與者那里尋求相關的幫助,以判斷你是否達到了預定目標。你可以根據指定好的議程堅持往前推進，盡管你不完全確定活動的每個環節中是否按照計劃行事。
結論
建立工作坊形式提供了一個受歡迎的方式并且緩解了苦逼的“開會”帶來的磨蹭拖沓的感覺。當工作坊實施的得當，它就能提供了很有建設性的解決問題的方式，同時讓每個參與者都很興奮的參與其中。工作坊是積極快樂的，就這兩點就足以讓你和你的組織拋棄無聊的會議，搞個頗有成效的工作坊吧。