本文將介紹UXR團隊的使用者研究（User Research）的各流程，包含撰寫研究計畫、招募受試者、準備問題、正式訪談、彙報（Debrief）、整合（Synthesis）等各個階段的基本內容。
本文架構：
先談談何謂「使用者研究」（User Research）
在正式介紹流程之前，應該先談談什麼是「使用者研究」（User Research）。
使用者研究，顧名思義，就是研究使用者（廢話XD）
因為一直以來多半在學界，所以對於「研究」這件事並不是那麼陌生（可見之前的轉職歷程）；
但在業界和在學術界的「研究」有很大的不同，通常業界的目的會更為明確，研究的過程也都是圍繞在這個「產品」的本身。
可能是前期開發時好奇目前使用者的使用喜好、經驗或需求；
也有可能是在產品中期想要測試產品是否有重大的問題；
也有可能是在既有產品已完成、需要更新版的迭代前，希望知道使用者他們目前使用起來的感受、以及下一版本需要新增或修改的新功能。
總而言之，在業界的使用者研究始終圍繞著產品，畢竟獲得了這樣的經驗和資源，就必須為產品做服務。
使用者研究方法
如同一般的學術研究，我們可以很粗略地將使用者研究先區分為量化（quantative）以及質化（qualataive）。
量化分析觀察的是大量的使用者的數據行為，在大公司通常會有專屬的Data Team來協助；而目前多數的UXR團隊則是以質化研究為主，選擇小數量的代表性使用者，深入觀察他們的使用流程以及反饋。雖然在公司各個職位有各自的專屬領域和專長，但實際上若能夠結合量化與質化分析，對於整體的研究必定有它的好處。
UXR的使用者研究流程
決定研究目標與研究問題
如同所有的研究，決定這次研究的目標與研究問題絕對是首要的；接下來所有的研究方法、受試者選擇、訪談等面向全部都是需要回答原先預設的研究目標和研究問題。所以這次的設定相當重要。
在軟體公司中，常常是由stakeholders（利益關係人）提出他們的需求，UXR團隊會協助他們確立這次的研究目標。
舉例來說，stakeholders希望知道新用戶在第一次接觸這項產品時，感受如何？有沒有什麼技術性的問題？他們是基於什麼樣的目標去使用這些產品？
由於stakeholders不一定只有一位，加上大家總是對於產品有很多的好奇，因此身為UXR就必須去協助他們縮限這次研究的目標，把所有想知道的事情去做優先度的安排，確認哪些問題能夠在這一次研究得出結果。
撰寫研究計畫（research plan）
針對這次的研究撰寫研究計畫，常見的研究計畫包含：
- background：過去有什麼樣的成果？這次為什麼會想要做研究？
- research objective：這次研究結束後，預期得到什麼明確的實質成果？
- research question：這次研究想要解決什麼樣的問題？
- methodology：研究的方法
- participants：研究預計邀請的受試者，包含人數、條件
- research schedule：這次研究預計所有內容的時程表
- budget：這次研究的預算
待研究計畫完成後，與stakeholders確認後即可開始動作。
設計招募表單（recruitment survey）並招募受試者
針對這次研究希望獲得的成果，找尋適合的受試者。
通常會先發出招募表單，邀請對於這次研究有興趣的使用者填寫。
但為了避免這些填寫表單的人為了想要入選而刻意填寫我們希望的答案，在招募表單內要盡量避免透露這次研究想要找的受試者類型。
表單內也需要事先寫好到時受試時的一些注意事項（如：費用、錄音錄影、使用軟體等），確保他們可以接受。
篩選受試者（screening）
收到受試者回覆後，針對這次的研究主旨來篩選適合的受試者。
除了依照他們所回答的答案之外，如果能事先從其他團隊或資料確認他們在使用產品時的行為，會對研究最後的結果更有幫助。
通知受試者
在確認好這次的受試者後，便可以開始通知受試者並協調他們的面試時間。
這個階段可以用E-mail或訊息確認，若用電話還可以進一步確認受試者的口語表達能力狀況。
準備訪問問題
針對研究問題與目標，開始撰寫細部的訪問問題。
在這個階段請越精細越好，例如一開始怎麼自我介紹、要說明哪些注意事項等，一開始都可以寫得很清楚。我過去總覺得這些東西應該不太會忘記，但事實證明很多小細節真的很容易在訪談當下忘記，所以還是盡量越仔細越好。
在撰寫時可以與組內同事、stakeholders確認有沒有特別想要問詢問的問題，並順出一個流暢的詢問流程。
確認當天任務分配
將面試時程運用Google Calendar之類的軟體記下來，並且邀請相關人員一同參加。
至少需要：
- 訪問者乙名：通常是負責本次研究的UXR，訪問用戶；如果因為跨國而有語言問題者則不限
- 筆記者乙名：記錄使用者所說的話，多半是其他的UXR同事，如果非UXR組內，會另外找時間向他們說明做筆記的注意事項
- 觀察者？名：依照需求，觀察使用者並協助記錄
Pilot Test
為求當天的訪談順利，通常會預先請公司同事、親友擔任Pilot Test的受訪者，協助測試這次的訪談是否順暢；如果有需要增刪問題的狀況，也可以即使修正。
正式訪談
正式訪談時，所有人員都要準時上線，待所有人就定位後就可以邀請使用者進來。
訪問員自我介紹並簡單介紹這次研究的目的，以及接下來的面試的大致流程，讓使用者大致有個心理準備。
如果當天有其他成員在場，訪問員也會介紹其他人員的目的僅是協助筆記；另外也要向他們請求口頭同意錄音錄影的權限。
開始訪談時，一開始會問一些比較簡易的問題來暖身（如請他們自我介紹等），並讓他們不要這麼緊張；
等到差不多後，就開始正式的訪談。此時，所有人都有各自的任務：
- 訪問者：大致依照順序來訪談，但可以視情況來調整訪談的順序。由於訪談可能會涉及使用者之前填的問卷內容，所以也務必先弄清楚使用者的基本資料
- 筆記者：盡可能越詳細地做筆記（就像語言學在做conversation analysis一樣越詳細越好XD 連pause、情緒都可以記錄）
- 觀察者：在如Figjam之類的筆記軟體上記錄當下的觀察
結束訪談前，訪問者要先確認其他人是不是有要補充的問題；也務必確認使用者是否還有想說的話。
一切都結束後，感謝使用者的協助，說明如何給予酬勞。
我們在每天的訪談結束後，通常也會再傳訊感謝使用者的幫忙。
彙報（Debrief）
這個詞要翻成中文有點難XD
基本上Debrief是每一次的訪談結束後都會做的事情，時間並不長，很快地請所有參加訪談的人分享他們的觀察點，大約花個5分鐘準備、撰寫，再花一點時間報告。
這是確保沒有缺漏什麼內容，也可以馬上把訪談當下重要的訊息highlight起來。
我在第一次Debrief完全不知道自己該做什麼，關於Debrief的目的、流程和相關內容，可見：
語言學學UXR | 在每場訪談後的15分鐘Debrief，補足使用者訪談的拼圖
整理
UXR整理並分類Debrief後的資料，並確認訪談當下的重要內容都有被記錄下來。
整理的方式並沒有對錯，只是方便後續的整理
每日彙整（daily summary）
有時候stakeholders並不一定會全程參與訪談，所以會統整每天訪談的內容給相關人員閱讀。
整合（Synthesis）
這個單字更難翻…
當所有訪談以及資料整理完之後，就會開始進行更大型的彙整，是報告前最重要的步驟。
這時需要再次確認研究目標、研究問題是否能藉由這次的研究訪談達成？所有訪談的內容都要能夠支持結果。
在這階段要進一步把所有原本的客觀觀察（observation）轉換成見解（insight），同時創建使用者旅程（user journey）、行為模式（pattern）、人物誌（persona）、執行項目（action item）等未來報告會用到的內容。
再進一步會開始根據現有的量化及質化資料順出報告的順序，以作為報告的基礎。
這部分未來也會再開專文討論。
報告
將這次的成果報告給stakeholders甚至是對本次研究感興趣的同事們。
後記
整個使用者研究的流程可能會因為公司、UXR團隊、執行者、研究方法而有些差異，但是大部分來說會依照上述這些內容完成。
因為也還在繼續學習中，這些內容可能在未來會不定時調整，也會慢慢記錄一些細項:)
如果有任何問題也歡迎隨時留言詢問哦！
感謝收看:D
如果您喜歡本篇文章，請幫我在下方的「拍手區」按圓圈圈裡的拍手圖案5次吧:D
您的舉手之勞，可以讓我得到 Likecoin 的回饋哦！
只要註冊／登入帳號（支援Facebook、Google帳號，註冊不超過1分鐘），只要替我按五次拍手，您不用支付任何費用，卻能給予我最大的鼓勵，讓我寫出更多的好文章哦！
