研究雙刀流：airbnb、Google、Spotify與趨勢科技中的使用者研究與數據科學協作
哈囉各位UX四神湯的讀者們大家好~本週筆者想與各位討論的是使用者研究如何與數據科學協作共同產生質性與量化兼具的洞察。
本文會分享Airbnb、Google與Spotify的協作模式，另外也會分享筆者在趨勢科技中的實作經驗，希望各位讀者在看完本文的分享後，也能與一起共同討論這個有趣的議題~
量化研究與質性研究分別解決了什麼問題？
在Spotify的這篇文章中，他們提出了一個名叫What-Why的框架，該框架的橫軸為量化研究(Quantitative)、質性研究(Qualitative)，縱軸為行為(Behavioral)、態度(Attitudinal)，並依據橫軸與縱軸切分為四個象限，再依據不同研究方法的特性將其媒合至該框架中，幫助各位研究員或數據科學家快速地尋找適合的研究方法。
就如同上圖中的What與Why，量化研究主要能夠幫助研究員或數據科學家了解的是“現象”，而背後主要的理論依據的是機率與統計。質性研究主要能夠幫助研究員或數據科學家了解的是“原因”，而背後主要的理論依據則主要是認知心理學。
當研究員或數據科學家對於問題發生的現象與原因都不甚了解時，就會需要進行質性與量化並進的研究，利用不同的研究方法彼此組合與互補，藉以拼湊出更趨向於事實(母體)的研究結果。
那麼，在一家大型的企業組織中，該如何進行質性與量化並進的研究呢？
組織架構、角色與職責？
在大型的組織企業中，許多公司會請使用者研究員進行質性研究，並請數據科學家進行量化研究，比如，Spotify、Google與Airbnb，而這三家公司的協作模式與組織架構約略如下(參考資料洽文末)：
airbnb擁有一數據科學家組合而成的數據團隊(Data Team)，其中除了數據科學家外，還包含了數據工程師(Data engineers)、商業分析師(Business analysts)、機器學習工程師(Machine learning engineers)、數據架構工程師(Data infrastructure engineers)與數據產品工程師(Data product engineers)，他們的研究範圍包含A/B Testing，細節工作包含定義指標(Define metrics)、確定數據的蒐集範圍(Specify which data to record)與建制數據工作流(Build data pipelines)等等。另外他們也會進行探索性的數據研究，除了建制數據模型外(Statistical Modeling)，也會產出洞察報告與數據儀表板(Create reports and dashboards)，最後為了讓各個團隊都有辦法進行簡單的量化研究，他們也會建制內部使用的數據工具(Build internal data tools)，並且建制學習資源以利其他擴張其知識系統(Develop educational resources for other teams)。可以看得出來，airbnb的數據團隊，主要針對的都是偏向量化研究與其相關應用的工作內容。
在airbnb釋出的眾多文章中，不難發現airbnb的數據團隊與研究團隊(包含使用者研究與市場研究)分別屬於獨立的團隊，彼此都獨立的依據不同產品團隊的需求向產品團隊提供支援。兩個團隊彼此工作的交集也較少，可能較少量化與質性研究同時進行的研究專案(?)。
然後我們來聊聊Google的狀況，
在Google的組織中，有一職位叫做量化使用者研究員(Quant UX Researcher)，隸屬於UX團隊。在Google裡，量化使用者研究除了具備數據科學家的專業能力外，還擁有UX的基本知識(果然是Google啊…)，量化使用者研究員的工作是應用數據科學來定義或回答UX問題。經常回答的問題包含：使用者做了什麼？ 使用者的目標是什麼？ 是什麼讓他們感到沮喪？ 在我們可能做出的產品選擇中，使用者會喜歡什麼？ 如何衡量成功？(參考資料洽文末)。
在Google中，量化使用者研究員所需要進行的工作與上述Airbnb的數據團隊的工作較為相似，主要的工作內容包含A/B testing的操作與探索性的數據研究，細節工作包含定義與衡量量化指標(Define and measure quantitative metrics)、透過程式代碼或統計模型來了解使用者行為(Develop code and statistical models to understand user experience)、依據現有產品設計與數據產生假設或研究計劃(Examine existing data and product designs to generate hypotheses and plans for high-impact research)，並且產出具有說服力的研究發現與可執行的設計建議(Make research findings convincing and actionable for both research experts and non-experts)。
然而，從參考資料中可以發現，在Google的工作環境與氛圍中，傾向較獨立的工作型態，往往是量化使用者研究員依據研究問題去開展獨立的量化研究。雖然相較於airbnb的組織架構看來，在Google中，使用者研究員與量化使用者研究員已經隸屬於同一團隊，但在彼此協作、共同進行質性加上量化研究的機會還是相對較少。
最後，讓我們來看看Spotify的組織架構與職責範圍，
在Spotify中，使用者研究員與數據科學家隸屬於同一團隊-產品洞察團隊(Product Insight Team)，且產品洞察團隊嵌入在產品團隊中。在Spotify中，每一項研究專案，產品洞察團隊都會融入使用者研究員與數據科學家的觀點，試圖做出質性與量化兼具的產品洞察。
在Spotify中，針對同一UX問題，同一研究專案可能會先請數據科學家利用量化方法進行數據挖掘、探索既有“現象”，如探索性數據研究，再著，請使用者研究員進行質性研究，依據該“現象”尋找背後的“原因”，如訪談、日誌研究。也有可能是先請使用者研究員進行探索性研究，挖掘洞察，如日誌研究，再請數據科學家依據該洞察產生相對應的假設，並利用A/B testing驗證其假設(參考資料請洽文末)。
筆者的自身經驗-趨勢科技 Trend Micro
在趨勢科技中(以大型企業團隊為例)，傾向在UX團隊中招募擁有雙刀(?)技能的使用者經驗研究員(Mixed-Method Researcher)，同時具備質性研究與量化研究的基礎知識與技能。然而，不得不承認的事實是，擁有雙刀技能的使用者研究員就算是擁有足夠的量化數據解讀或分析的技能，也可能對建制數據工作流、數據架構與數據模型不甚熟悉(比如筆者本人我XD)。
因此，在趨勢科技中，當團隊需要進行量化研究時，使用者研究員會與產品團隊中的數據科學家，或是具備基礎資料科學知識與能力的工程師協作，由使用者研究員定義假設、訂定需要蒐集的數據形態與衡量指標，並由數據科學家或工程師處理數據工作流、數據架構等相關工作，最後再由使用者研究員進行資料解讀並產出洞察報告。而其他以質性研究方法為主的研究專案，就由使用者研究員獨立完成。
質與量兼具的研究專案案例？
Spotify
在Spotify的這篇文章中，有提到一個產品洞察團隊針對“略過廣告”的功能所進行的質性與量化兼具的研究。
Spotify的產品團隊以澳洲做為試點發佈了“略過廣告”的功能，並在功能發佈不久的期間一邊進行量化研究(監控使用者行為數據)，一邊進行質性研究(日誌研究)。在研究初期，數據科學家透過監控使用者行為數據，定義了不同的使用者族群，而使用者研究員則是依據這些使用者族群來篩選日誌研究的受測樣本。
而除了樣本的篩選外，在文章中也舉了另一個透過數據追蹤(量化)與日誌研究(質性)共同產生洞察後在產品中進行改善的例子：
數據科學家發現有一群使用者在略過六個廣告後即停止略過廣告的行為，當時數據科學家們對該行為感到不解，因此請求使用者研究員在日誌研究中探索其中的原因，後來發現這群使用者自行將“略過廣告”與“略過歌曲”的兩個功能相互連結起來，由於Spotify只能讓使用者略過六首歌曲，因此這群使用者也認為他們只能夠略過六個廣告(事實上他們可以略過無限個廣告)。也因此，產品團隊決定在略過功能介紹的介面中加上“無限略過”廣告的標語，藉以改變使用者的行為。
趨勢科技 Trend Micro
一直以來，趨勢科技的大型企業團隊都擁有良好的市場回饋機制，銷售團隊(Sales)與客戶支持團隊(Customer Support)總是會將客戶的抱怨與痛點回饋給產品經理(Product Manager)，然而，當全球的銷售團隊與客戶支持團隊都將所有的客戶抱怨與痛點回饋給產品經理時，產品經理就會發生不知道如何排定優先級(Prioritization)的問題。另外，由於各個的銷售團隊與客戶支持團隊所提供的數據或是脈絡(context)都是區域性的，產品經理在眾多的數據與脈絡中總是會發生不一致的問題，導致產品經理在排定優先級時，也不知道依循哪個區域的數據或脈絡做為基準，可能導致優先級與痛點的嚴重程度不相符的問題。
舉個例子：北美地區客戶支持團隊頻頻向產品經理訴說A功能是如何的被客戶抱怨，問題很嚴重，而歐洲地區的銷售團隊也頻頻地向產品經理訴說B功能是如何的被客戶抱怨，問題也很嚴重，希望產品經理可以盡快的將開發資源投入，改善產品功能。
假設，A功能與B功能的問題一樣嚴重。產品經理為了排定優先級，因此向北美地區的客戶支持團隊詢問客戶使用A功能的使用頻率，也向歐洲地區的銷售團隊詢問客戶使用B功能的使用頻率。然而，即便是北美地區的客戶支持團隊回應客戶使用A功能的使用頻率為一天多次，且歐洲地區的銷售團隊回應B功能的使用頻率為一月多次，產品經理還是發生無法排定優先級的問題。
為什麼呢？
因為角色與情境不同，也就是脈絡不同。客戶支持團隊只有在客戶遇到問題時才會與之聯絡，因此客戶支持團隊所面臨的通常並非是客戶的平常穩定狀態，因此，可能會使得A功能的使用頻率更加頻繁。而銷售團隊往往是在客戶要更新產品使用權(license)或是新購買產品時才會接觸到客戶，所以即便是B功能的使用頻率不高，但也表示可能會成為客戶決定要不要花錢的重要決策因素之一。
在這樣的時刻，量化的數據追蹤再加上質性的脈絡整理就顯得很重要，各地區的使用頻率可以利用全站數據追蹤來做分析，北美地區與歐洲地區有多少使用者經常使用哪些功能，都能夠一覽無遺，對於產品經理要進行優先級排序時，也能提供中立且宏觀的參考依據。
最後，附上本文的參考資料，本次筆者的參考資料大多都是由 Jeff Sia 大大提供，感謝Jeff 之前的幫助，小妹受益良多，也因此思考了許多組織內的角色與分工。
Reference:
Spotify:
Google:
以上，UX 四神湯，感謝各位的閱讀，也期待各位讀者與筆者一同討論這個有趣的話題~
偶們下週再見捏 :)
