研究雙刀流(二)：量化使用者研究專案實作流程分享
嗨！各位UX四神湯的讀者們大家好，繼筆者上次談到airbnb、Google、Spotify與趨勢科技中的使用者研究與數據科學的組織架構與協作模式後，本週筆者想與各位進一步分享在趨勢科技內使用者研究員與數據科學家一同協作量化使用者研究的實作流程。
在上一篇文章中，筆者有提到趨勢科技傾向招募擁有雙刀技能的使用者研究員，即具備質性與量化研究能力的研究員，然而，由於使用者研究員(比如小妹筆者我)對建制數據工作流、數據架構與數據模型不甚熟悉，因此需要在進行量化研究時與數據科學家合作。本文依據筆者自身與其他趨勢科技使用者研究員的經驗將量化使用者研究的實作流程分為六個步驟：
- 制定假設 Hypothesis
- 訂定實驗/研究計劃 Experiment/Research Plan
- 訂定數據計劃 Data Plan
- 數據埋點與測試 Tracking & Testing
- 數據監控與清理 Monitoring & Cleaning
- 數據分析與結果 Data Analysis & Results
以下篇幅，筆者將依據該實作流程一一分享各個步驟的實作經驗。
1. 制定假設 Hypothesis
趨勢科技自去年開始推行“假設驅動開發(Hypothesis-Driven Development, HDD)”，意即開發團隊在開發新功能/改善既有功能時，需要先釐清目標，並再針對該目標訂定不同假設，並依據假設制定出可行的解決方案(solution)，再訂定好可驗證假設的數據指標，藉以在功能上線後加衡量該假設的成效。
關於“假設驅動開發(Hypothesis-Driven Development, HDD)”的相關網路文章非常多，感興趣的小夥伴們可以參考以下文章，筆者即不再贅述。
因此，在此階段，趨勢科技的產品經理(Product Manager)會和開發團隊、使用者研究員、UX設計師及數據科學家一同釐清產品所面臨的問題或產品策略(Product Strategy)，並由使用者研究員制定假設。在假設中，會明定顧客類型、所面臨的問題、欲開發的解決方案、衡量指標，與預期成果。在制定多個假設後，產品經理會訂定各個假設的優先級。
舉個例子，趨勢科技有一產品的on-boarding流程共有七個步驟，而產品經理與開發團隊利用了漏斗圖(Funnel)密切地監控七個步驟間的轉換率。在此on-boarding流程中，產品經理與開發團隊發現有在註冊帳號的轉換率偏低，因此訂定了假設多個假設，如：
假設一：客戶忘記帳號/密碼了
假設二：客戶沒有權限登入/創建帳號
假設三：xxxxx
假設四：xxxxx
在統計客戶在註冊帳號的過程中後端傳回的錯誤代碼(Error Code)後，發現有許多客戶有忘記帳號的現象，因此團隊選定了第一個假設，並將欲開發的解決方案、衡量指標定義清楚：
"若提供忘記帳號的服務給忘記帳號的客戶，即可幫助這些客戶找回帳號密碼，並成功登入。我們可以依據該群客戶的"忘記帳號密碼"的點擊率與成功登入率來驗證該服務的成效"
2. 訂定研究/研究計劃 Experiment/Research Plan
當團隊選定預計執行的假設後，UX設計師即會著手設計新功能的User Flow，並且與工程師們一同討論開發實作的方式。在此過程時，使用者研究員的責任有兩個，一是以使用者的視角審視User Flow(即Design Critique)，確保User Flow符合使用者的使用情境。另外，若User Flow的過程中有涉及會影響量化使用者研究的內容的話，如in-app survey、marketing campaign，使用者研究員也需要積極且即時的與Writer/ Content Strategists討論。
第二個任務則是開始規劃量化使用者研究的實驗計劃。在規劃量化使用者研究的實踐計劃時，通常筆者會使用slide將面臨的的問題、欲開發的解決方案、實驗方法、衡量指標製作成示意圖表，並與各Stakeholder們解釋共有多少圖表會在功能上線後會被製作成數據儀表板(Dashboard)並作為監控數據的工具、而這些圖表應該如何解讀，解讀出的訊息如何能夠回答團隊所遇到的問題，而該圖表又能夠如何幫助團隊訂定出下一步的後續行動(Follow-up Actions)。
延續上述的例子，在"忘記帳號密碼"的功能開發前，使用者研究員會製作以下slide向各stakeholder們說明在後續的數據分析中，將如何進行實驗，並說明如何驗證分析“忘記帳號”功能的效用。
如下圖所示，由於開發團隊普遍相信”忘記帳號密碼”的功能能夠有效提升註冊帳號的這個步驟的轉換率，因此決定實驗的方法為單純的數據追蹤，不額外進行A/B testing。並在此功能上線後追蹤抵達登入頁面的客戶數，也額外統計曾經有發生忘記帳號密碼的客戶數，並且統計在這群客戶中又有多少客戶點擊了“忘記帳號密碼”的連結，並統計點擊過“忘記帳號密碼”的客戶中又有多少客戶後來成功登入了系統。經過這樣的統計方式，可以有效地看出“忘記帳號密碼”的新功能為註冊帳號的這個步驟提升了多少的轉換率。
3. 訂定數據計劃 Data Plan
在訂定好實驗/研究計劃後，使用者研究員、數據科學家與前端工程師及後端工程師即可開始密切地討論數據採集的實作規格(Spec)。
在此階段，使用者研究員會使用表格來明定各個前後端行為的數據採集方法(如該資料可能透過前端使用者行為採集或透過後端行為採集)並為各前後端行為訂定數據採集的事件名稱(Event Name)。
下圖為根據上述案例所寫訂定的數據採集的實作規格，可以看到item #1是記錄有多少客戶有過sign-in/sign-up失敗的經驗，追蹤的方式是利用後端事件，事件名稱為“authentication_failed”，而失敗代碼為“400”，而item#2則是記錄有多少客戶有點擊過“忘記帳號密碼”的連結，追蹤的方式是利用前端事件，依據Matomo Tag Manager的機制又可將事件依據Event Category、Event Action與Event Name，可以看到筆者分別將Event Category定義為“Sign-in/sign-up”、Event Action為“click”、Event Name為“forget_password_account”。
除了定義事件名稱外，在此階段，數據科學家會開始規劃數據工作流(Data Pipeline)與數據架構(Architect)，並且確保每個資料庫中的各個表格有辦法相互參考(reference)，並整理成表後與使用者研究員溝通。
在此階段，筆者非常建議使用者研究員自行定義數據採集的事件名稱，如此一來，不論是使用SQL或是數據分析工具(如Google Analytics)都會相當方便，不需要一一詢問數據科學家或是工程師每個事件名稱的意義，能在後續進行數據分析時節省許多時間。
4. 數據埋點與測試 Tracking & Testing
在趨勢科技中，前端事件的數據埋點可能由使用者研究員或前端工程師進行。當前端工程師將產品實作完成後交由QA工程師進行測試時，使用者研究員即可開始進行前端數據埋點與測試。
由於趨勢科技是使用Matomo Tag Manager以及Pendo (這兩個工具差不多跟Google Tag Manager長得有87%像)，因此對於使用者研究員來說並不是十分困難，只要了解Google Tag Manager的運作方法與實作方法即可快速上手XD。若遇到較複雜的事件埋點時，可以再請前端工程師協助一同進行數據埋點的實作與測試。
在此階段中，對於筆者來說較麻煩的事情是環境的問題，由於許多介面可能只會出現在特殊的情況(如Error handling的user flow)，因此需要QA協助額外建制該特殊情況的環境後才可進行數據埋點，對使用者研究員與QA來說都需要額外多花費許多時間。
5. 數據監控與清理 Monitoring & Cleaning
在數據埋點與測試完成後即可開始進行數據監控與清理，在此階段，會是數據科學家與使用者研究員能夠第一次見到來自各個數據源的數據被整合在一起的時刻，因此，一些事前沒想到的數據工作流的問題就可能浮現出來。因此，進行數據監控並且在監控數據的過程中若發現有不預期的狀況發生時，數據科學家即會進行數據清理或是修正數據工作流以確保數據的正確性。
6. 數據分析與結果 Data Analysis & Results
在數據監控與清理階段完畢後，數據變得開始穩定且可信，此時，使用者研究員與數據科學家即可開始進行數據分析。在趨勢科技中，數據科學家一般使用Tableau來建置儀表板(Dashboard)以幫助各個Stakeholder們(包含使用者研究員)可以快速且即時的拿到所需的資料，有時數據科學家也會額外寫一些SQL Query來回答較複雜且特殊的問題(常常是使用者研究員提出來的複雜問題，但使用者研究員如小妹我又寫不出複雜邏輯的Query Statement，所以只好請數據科學家大大們幫助小妹我= =)。而使用者研究員透過由數據科學家所建立的儀表板中的數據來解讀出使用者洞察(User Insights)，並製作成報告向各Stakeholder們解釋並協助且建議Stakeholder們下一步的後續行動(Follow-up Actions)。
以上，是趨勢科技裡使用者研究員與數據科學家進行量化使用者研究的實作流程與細節分享，希望以上內容可以為各位追求質與量兼具的研究員一些啟發。也期待有更多讀者可以與筆者一同討論雙刀研究的話題油~
