工作坊經驗分享-跟著UX設計師小步快跑，快速迭代
專案背景
開始分享之前先來簡單敘述專案背景，本專案是建築管理的產品開發，產品將應用於建築業管人員的建築報修、維運等功能。而這次的產品採取與客戶共同協作的產品開發方式，由海棠設計引導本專案的 UX 規劃、介面設計以及產品易用性測試，程式開發的部分則由客戶負責。
而此次的協作最大的挑戰在於，如何在有限的時間及技術限制下快速釐清多元使用者（管理者、工程師、維修人員、報修職員）之間的互動關係以及將目前的紙本流程進行數位化設計，規劃出符合多元使用者需求的介面與體驗設計。
為了幫助專案成員更快速的瞭解產品需求與產業Know-how，我們將採用Scrum的方式進行單元拆解與設計。以下將和大家分享我們在工作坊所使用的方法和心得。
工作坊主題大鋼
一、工作坊的規劃
1.利害關係人與使用者輪廓
2.使用者歷程
3.功能重要性與開發排序
4.規劃工作坊主題單元和順序
5.慎選參與人員-在於精不在多
6.製作工具與文件
7.預告工作坊主題二、工作坊的執行
1.介紹專案成員及角色
2.說明每次工作坊的目的
3.交付的資料貼於牆上檢視
4.確保工作坊目的是否有達成
5.重點事項紀錄三、工作坊的追蹤與交付
1.追蹤待辦事項
2.製作線上資料與文件
依功能單元切分成數個微型工作坊
首先考量到時程緊迫，將工作坊依功能單元拆分成數個微型工作坊，優點是可以讓專案成員更專注在單一功能的流程與問題上做細節討論，而且當一個單元完成後，工程師就可以參考原型圖(Wireframe)進行 SA，待產品經過使用者測試的調整後，即可以同步進行開發，以加速專案的進程。以下將工作坊分為工作坊的規劃>工作坊的執行>工作坊的追蹤與交付 三個階段作說明。
一、工作坊的規劃
1. 利害關係人與使用者輪廓
不單是工作坊，在任何專案開始前，我們都必須清楚知道與產品相關的利害關係人和使用者輪廓，
完整與精準的使用者輪廓可以幫助專案成員在設計或開發時跳脫「為自己設計」的思維
站在使用者的角度思考並了解其需求，確保專案在執行的過程不會偏離軌道。
而你可能會想說使用者輪廓不就是客戶窗口說的那樣嗎？為何要在工作坊做一次，嗯⋯這就是很玄的地方⋯⋯，舉辦幾場工作坊的經驗告訴我，雖然隸屬同公司但大家對於使用者輪廓的描述還是有落差的，為了避免後續在溝通上有認知落差，如果有機會舉辦工作坊，都會在工作坊開始前先和客戶共同完成使用者輪廓的定義，讓專案成員對於使用者的想像是一致的。
2. 使用者歷程
定義好使用者輪廓後，接下來就是要了解，各個使用者的使用歷程，關於使用者歷程的操作方式，網上有很多的文章說明，這邊就不多贅述，主要是透過使用者歷程了解整體流程概況並找出使用者痛點，作為日後不管是在探索階段、設計階段、測試階段、甚至是迭代優化時的重要參考依據。
因為本專案涉及的產業Know-how，主要的使用者們皆以工作輔具的角度操作本產品，因此初期我們將各個使用者操作流程與互動關係勾勒出來，主要是讓專案成員大概了解每個使用者會對應到的功能以及先後順序關係，例如:
(1)『報修人』填寫報修單 > 『工程師』將報修單派發成任務
(2)『管理者』派發任務 > 『維修人員』維修後填寫耗用資源
(3) 『管理者』審核放行 > 系統通知『報修人』維修結果。
3. 功能重要性與開發排序
產品開發一定有時程壓力，因此同客戶討論功能的重要性與必要性，並依照客戶內部資源可支援的程度進行功能開發排序，也作為我們工作坊的主題排序參考。
4. 規劃工作坊主題單元和順序
我們會先根據客戶給的功能清單或是架構圖，以此推估每個功能的流程和頁面數，並以功能之間的關聯程度與開發順序去規劃工作坊單元討論的排序和時間，例如報修功能又細分請求報修和請求管理，以流程面來講必須先有請求報修才會有請求管理，頁面資訊和流程會有關聯性，因此在討論時儘量一併討論，減少重新 review 資料的時間。
5. 慎選參與人員-在於精不在多
依據工作坊性質不同，參與的人數及成員背景也不盡相同，因本專案開發的主要目的是要提供第一代的產品原型，因此主要的目的將是釐清各使用者在當前的使用歷程與痛點為何，而非產品創意發想。因此在人數的限制上建議不要超過 10 人，且相似背景的成員以不超過 2 人為主，最好是選擇對工作坊主題有影響力與決策權的利害關係人一起協作，能有效達成工作坊目的才是最重要的，太多不相關的人參與，反而會大大降低協作的效果。
6. 製作工具與文件
根據每次工作坊的主題，規劃合適的方法或工具，目的是協助專案成員順利進行討論與紀錄，例如在釐清多元使用者輪廓時，可以事先製作人物照片素材，讓專案成員在進行使用者輪廓描述時可以共同篩選對應的照片，除了增加共識外，也為初次合作增加了互動性，熱絡的討論也對後續專案能更順利進行，但切記不用花費太多時間，能達成目的就好，也可以現場打開圖庫直接請專案成員挑選。
7. 預告工作坊主題
一切都準備好後，請提前告知專案成員工作坊內容，讓專案成員有足夠的時間為主題做準備，客戶也會有足夠的時間針對主題邀請相關利害關係人加入工作坊，如有與主題相關的資料也可以在這時候提供，可以幫助成員在工作坊前期更快速進入狀況。
二、工作坊的執行
1. 介紹專案成員及角色
不僅僅是介紹名字那麼簡單，必須說明自己在此專案的角色與專業背景，主要是可以讓主持人和專案成員知道在工作坊進行過程中遇到問題時，該找誰討論或表態才能獲得到最大的效益。
2. 說明每次工作坊的目的
主持人會說明本次工作坊預計討論的主題及目的，接著請客戶對於本次主題的資料進行說明，讓專案成員對主題有共同的知識背景，減少認知落差。
3. 交付的資料貼於牆上檢視
在工作坊開始前先將原型圖放大輸出，並按照操作流程貼於牆面上，方便專案成員檢視，並請專案成員依自己擔任的角色和專業背景提出問題，例如工程師針對技術面做發問、UX 設計師則關注在使用者操作面向等等，討論過程中也可以發點點貼紙或便利貼，讓專案成員先在有疑問的原型圖上做記號，最後按照流程依序討論，從中釐清專案成員的考量，藉由密集的單元討論，讓產品在不論是技術面、操作面、商業策略面，都可以在設計限制下找到最佳的解法。
4. 確保工作坊目的是否有達成
主持人最重要的任務就是要能在有限的時間內引導專案成員進行討論並形成共識， 最後要確認工作坊的目的是否有達成，是否有解決問題。
5. 重點事項紀錄
不需要逐字紀錄，只需將討論過程中的決議與共識紀錄下來，如在討論過程中有未釐清的事項，可在會議尾聲再次提出討論，如無法在這次工作坊中釐清，請紀錄在待釐清的事項及待辦事項中，供後續專案成員追蹤。
Tips:・重視溝通:先把時間花在溝通與嘗試，產品的設計進程將更事半功倍。・溝通流程:理解核心問題 > 快速思考 > 建立共識。・建議在討論的過程遇到複雜的問題可以善用白板將問題寫或畫在上面做討論，方便專案成員想像，也更容易理解。・討論過程中遇到討論很久的問題或是延伸問題，且不影響接下來的討論的話，可以先記錄下來，待其他事項討論完後再繼續討論，抑或是各自回去討論完後下次工作坊找時間說明討論結果。・如果關鍵角色或是決策者無法出席，建議將工作坊改期，不要浪費時間開一個沒有結果的會議。
三、工作坊的追蹤與交付
1. 追蹤待辦事項
每次工作坊結束後，專案管理人會依據工作坊紀錄中的待辦事項或待決議事項做持續追蹤與提醒，例如製作原型圖所需的資料或是技術面問題需要請客戶與內部決議的事項，都會請專案管理人協助提醒與收集。
ps. 說到收集資料真的是個學問，不只是簡單的收集而已，還需要過濾整理才能使用，可怕的是好不容易整理好，突然又來個更新版…呵…共勉之。
2. 製作線上資料與文件
將每場工作坊的紀錄及產出，放在線上供所有專案成員檢視與參考，除了方便找尋資料外，也可以讓資料保持較高的變動性及即時性，例如使用者歷程及原型圖會隨著每次討論而調整，線上文件可以讓專案成員即時給予回饋。
體悟
商業策略 VS 技術限制 VS 使用者經驗
上述看似風平浪靜的分享，實際在操作的過程中也遇到幾次的激烈討論，除了專業術語溝通問題外，就是要理解不同專業背景與角色所關注的問題，同樣的畫面大家看問題的出發點都不盡相同，例如某功能的出現對使用者來說會有很棒的體驗，但是對工程來說因為技術的限制會需要耗費更多的時間製作，而就商業策略來說這功能可以是待產品上市後，累積一定的客群後再提供的附加價值功能，這時就要共同討論權衡出最有價值的解法取得共識。
挖掘核心問題
前面提到的議題，都是因為深入挖掘了核心問題，才能做出有效的溝通，而除了本專案外也常常在其他專案遇到客戶只會跟你說「我覺得這功能不需要做」，這時候千萬不要傻傻地就說「好喔」，要引導他們說出想法甚至進一步挖掘原因，知道原因才能知道要怎麼解決問題！因為他們看到的只是其中一個解決問題的結果，要先了解問題的核心才能進行有效的溝通。
結語
不知不覺打了落落長，其實辦這麼多場工作坊最重要的核心目的就是可以跟直接利害關係人面對面討論問題和快速產生共識，如果沒有做到這兩項那工作坊就沒有意義了。
當然每個專案都不一樣，適合的方法也不同，本文章提及的工作坊主要是以協作開發為目的，適用在時間有限的情況下功能流程複雜且多元使用者的專案中，可以讓專案成員快速釐清多元使用者面貌及功能流程並快速做迭代優化，希望能提供遇到類似專案類型的大家一個參考，以後會再分享不同類型的專案我們有哪些玩法。
切記工具和方法是死的，如何活用在合適的專案上，創造價值，才是厲害的地方！
ps. 此專案後續還有使用者測試環節，包含原型製作、任務腳本設計、受測者篩選、場地佈置、測試方法等，有機會再跟大家分享其中的酸甜苦辣 😏
