A/B testing的奧妙，我是如何運用在設計過程之中?
分享這幾年跟A/B testing “糾纏” 的經驗， 著重在如何運用A/B testing在設計過程和面對它的心態
前陣子在幫一位新人設計師做入職訓練，分享團隊是如何設置、觀測和分析A/B testing實驗，在我滔滔不絕講解之後，她只簡單問了我：「這不應該都是數據分析師該做的嗎？」
當下深思了一下… 想到在加入這間公司之前，我也是一樣的想法…
但在我們公司，做實驗這件事，沒有該是“誰”的工作，因為只要在產品上的任何改動，無一不A/B testing，在強調”own it”和數據驅動的文化下，身在產品團隊的成員都被期待能夠運用A/B testing，幫助產品成長。
於是我興起寫這篇文的想法，分享這幾年跟A/B testing “ 糾纏”的經驗， 著重在如何運用A/B testing在設計過程和設計師面對A/B實驗的心態，希望這些分享對大家在產品設計的路上有所幫助。
A/B testing看似深似海，身為設計師的我們該懂多少，才能運用自如？
那就先來聊聊如何進行一個A/B testing實驗？
A/B testing是軟體開發過程常使用的方法，它是將A(原版)和B(新版)、或是更多不同版本，在同一時間，隨機分布展示在不同的用戶面前，來觀測不同版本之下的指標表現，協助團隊決策改動或新功能是否對用戶和商業有價值。
這邊我運用過去的專案，來舉例說明：
目前平台上使用儲存商品功能的用戶只佔了20%，明顯還有進步的空間，經過調研，發現用戶不太容易、甚至不知道我們有提供這個功能。於是我們決定當用戶在瀏覽商品詳細頁，展示一個提示泡泡(tooltip)在儲存功能附近，提示用戶使用。
在功能開發和測試完成之後，我們就會開始進行實驗。
那就開始來實驗啦！
依據實驗階段，主要分為三大步驟：設置、觀測和分析，以下會逐一搭配案例說明。
步驟1: 設置A/B testing
在設置A/B testing，我們會進行以下的步驟：
1. 定義假設: 新的改動會造成什麼用戶行為和指標的變化？
在制定假設的時候，我們會包含三大部分：
- 要做的改動
- 改動的目的
- 期待的指標變化
假使我們提示用戶使用儲存功能並且告知使用後的好處（我們要做的改動），會加強用戶使用這個功能的動機(改動目的)，進而提升儲存功能的使用率(期待的指標變化)。
💡補充知識：(1)指標選擇上，建議可以搭配領先(leading) 和後續(lagging)指標。
在我上面提到的案例中，使用儲存功能的用戶數量，就是leading指標，改動後，能較迅速看到變化，直接撼動的指標。而購買商品的用戶數，是lagging指標，它是因應改動後的行為轉變而帶來的指標變化(e.g., 儲存後，用戶可以方便回訪商品，增加購買機會)，需要一段時間，才能有可能看到效果。
兩相搭配，能夠較完整的推估用戶是否發生預期的行為改動，進而達到商業效益。(2) A/B testing分為比較型(comparative)和非劣性(non-inferiority)類型。當要比較B版(新版)設計比A版(原版)好的時候，我們通常是採用比較型(comparative)，觀測主要指標是否有顯著的正向表現，像是案例中的就是這一類。但有時候，一些改動是因為商業需求或是技術問題需要上線的，在沒有著重特定的預期變化時，我們會採用非劣性(non-inferiority)的方式來觀測，確保這些改動，不要傷害公司的主要指標。
2.選擇樣本：要觀察哪一類型的用戶？要多少數量？
由於我們設計是在用戶瀏覽商品詳細頁，才會出現提示，所以我們會將觀測樣本限縮在“瀏覽過商品詳細頁的使用者”，進行A/B分流 (通常是50% / 50%)。因為只有這群用戶會看到我們所進行的改動，這樣才能夠更準確地衡量所帶來的影響。
3.估算實驗時間：透過工具*來計算實驗需要進行多久，才可能會有 “顯著” 可信度較高的結果。
我們會依據用戶流量、主要指標在A版(原版)的轉化率和期望帶來的最小改動值，來推估實驗需要跑多久*，才會有比較大的機率得到可信度高、顯著客觀的結果。
*有現成的公式可以協助計算
以案例來說，
若A版(原版)商品詳情頁：
- 流量10000人次 / 天 (Average daily visitors)
- 使用儲存功能大概是10% (Current conversion rate, 又稱Base rate)
- 這次改動我們預期推測可以提升5% (Desired lift, 又稱minimum detectable effect)
這樣算下來，大概是12天，但考量到“季節性”的變因(週間購物頻率低，週末購物頻率高)，我們通常會設成以週為單位的週期，所以會是兩週14天。
在置信水平(confidence level)95%和檢定力(statistic power)為80％*的前提下，我們需要14天的時間，才有可能觀測到增加5%的使用率。
*以下會有補充說明
💡 補充知識:A/B testing永遠都存在誤差，我們能夠做的就是將誤差減低到最小，這邊會考慮幾個因素：
(1)隨機抽取樣本，確保公平
(2)樣本數越多，準確度相對會提高
(3)了解偽陽性&偽陰性出現機率的風險(延伸說明)偽陽性(False Positives)，譬如醫院檢測時，把男人診斷為懷孕。
當沒有發生，但實驗判斷為有發生，稱為第一類錯誤(Type I error)，也稱為偽陽性。在產品上若發生這個錯誤，你做的一個改動，用戶其實一點感受都沒有，但指標卻出現顯著成長，誤將這個改動上線。偽陰性(False Negatives),譬如把懷孕的女人，診斷為沒有懷孕。
當有發生時，實驗判斷為沒有發生, 稱為第二類錯誤(Type 2 error)，也稱為偽陰性。這個錯誤反映在產品設計上，就是你做的一項功能對用戶很有幫助，但卻沒被檢測出來，最後反而移除了這個有益於用戶的功能。為了減低上述兩個錯誤的發生機率，我們會設定實驗的顯著水平(Significance level)和檢定力(Power)。A/B實驗常用的顯著水平是在5%，意即實驗有5%的機率會發生誤差，值越小越好，代表誤差機率越小，這可以對應到置信水平(Confidence level)為95%(=100%-顯著水平)，意指在每次測試時，儘管A&B版沒有差異，在5%的機率仍會顯示出有差異(=偽陽性)。而檢定力，多數定義在80%，意即有80%的機會我們會觀察到A和B版是有不同的差異(避免偽陰性)。在這些數值設置下，能較有把握得到可信度較高的顯著結果，協助團隊做決策。(這部分屬於統計學的範疇，在應用上大致了解概念可以幫助你判斷實驗得到的數據可信程度，若有興趣可以查詢這裡)
有了以上這些設置後，你的實驗設計就大致完成，就等團隊同意，擇期開啟實驗(緊張)。
步驟2: 觀測A/B testing
實驗開啟後，你所設定的用戶群體就會被隨機的分流在A或B的群組，我們通常在一兩天內，會觀察是否有指標異常極端飆高或降低，這有可能是改動有bug或是tracking有問題，這需要與團隊溝通，是否暫停實驗，進行檢查。
若在一兩天內，沒有極端狀況發生，就建議是以週期性的方式來觀測(每7天來觀測)，不需要天天都來看上升或下降了沒(這可不是看股票行情呀…)。
會有這樣的建議，是因為在設定週期的指數表現，可能都不是在流量足夠下所產生的變化，也可能參雜週間的變動，所以可能是偏頗的結果，也浪費寶貴時間。
步驟3: 分析A/B testing
1.決策改動是否上線
實驗週期到達後，每個指標會因應敏感程度，分別呈現：顯著提升、顯著降低或是不顯著(無法看出提升或下降，多數)
以範例來講，實驗結果中我們看出B版(新版)
- 主要指標：使用儲存功能的用戶顯著的成長 (3.57%)
- 其他相關指標：訂購儲存商品的用戶顯著增加 (2.75%)
- 健康指標：商品訂單、取消、客服、效能…等指標，沒有看出顯著差異(看不出有無提高或下降)
從這樣的表現，我們可以推斷這個改動提升了使用率，也提升用戶與這個功能的交互，在沒有顯著傷害健康指標的狀況下，我們決定上線這個功能 🎉。
2. 挖掘洞見，啟發產品設計點子
除了協助決策這個功能是否上線，我們有時候還會從實驗結果中挖掘洞見，激發我們迭代的想法，像是從這次實驗，我們觀測到未登入用戶的使用率佔了22%，因為未登入用戶，無法享有進階的儲存功能，於是我們就想到把這個當作賣點，吸引他們來登入，進而提升用戶黏度。
但…實驗沒有顯著結果，分不清楚哪個版本比較好，該怎麼辦？
- 產品目前的流量是否足夠讓你看到顯著成果？
流量多寡會影響實驗設置的天數，我最常遇到的狀況是頁面的流量太小，導致實驗天數拉長。記得曾經在一個子頁面的實驗設置，計算下來需要跑將近6個月的時間，當下我們就決定暫緩這個優化改動，將其他流量較多的頁面優先級提高。 - 選擇合適的主要成功指標
省思你的實驗假設和主要成功指標的關聯性，預期你的改動會帶來什麼用戶價值，選擇合適指標。
譬如我們的案例主要指標是使用儲存功能的用戶數量增長，因為我們的目的在於讓用戶利用這個工具，協助他們做購買決定，而不是期許他們購買商品(當然商業上，我們是希望增加營收的，但做的優化並不全然是圍繞在這之上)。 - 選擇的樣本族群是否精確？
樣本選擇，需要確保與改動的相關性。譬如：我們做的改動是在商品詳情頁，所以我們的樣本是以有拜訪這一頁的用戶為主，而不是全平台的用戶，這樣能夠確保我們不會導入無效樣本，導致提高不顯著成果的風險。 - 很不想說，但…一試再試，若還是不顯著，就只好認命了….😂
這就有可能就是你的改動影響力不夠大，用戶無感，有沒有這個功能，都無差(好桑心)，在這樣的狀況之下，團隊會一起來討論是否要將改動上線，在我的經驗中，絕大多數，我們都會秉持著科學精神，停止實驗，繼續迭代或是放棄。僅有少數是商業策略因素，一定得上線不可，我們才會以 “策略因素” ，將改動上線。
在設計過程中，我在什麼時候運用A/B testing？
在整個產品設計過程中，我會在什麼時候借助A/B testing的力量，來輔佐我決策？
推測(Speculate)
推測用戶對於類似功能(改動)商業效益和行為變化，作為依據
普遍來說A/B testing是在功能或改動完成後，而進行的驗證過程，而在我們公司，因為A/B testing的模式發展成熟，所以有很多可參考的資料。所以我從ideation 階段，就已經開始借鑑A/B testing之力，來輔佐設計方向。
通常當我們腦中有個大略的想法，就會先去搜尋公司團隊內是否有人做過類似的功能或改動，並且參考他們當時的指標表現，來佐證我們的想法是否具有潛力。
這也是為何我們在進行A/B testing要有完整的設置實驗的文檔紀錄，因為公司其他團隊有招一日會來閱讀你的實驗，找尋靈感。
(但這僅適用在公司有完整收錄 “古今往來”A/B testing實驗紀錄的前提下)
測試(Test)
測試設計概念是否符合用戶期待
秉持著 “雞蛋不要放在同個籠子裡”，針對那種大規模的設計改動，我們通常會先運用一些開發小成本的方式，將”概念雷同”的設計想法展示在用戶面前，觀察觀察是否符合他們的”胃口”，進行A/B testing，再決定是否投資重本，繼續發展。
舉例之前另一個專案，我們希望將當地受歡迎的支付方式能見度提高，這樣用戶的支付成功率會相對應提升，完整的設計包含：
(1)在結帳頁把當地支付方式的圖標，放在前面幾位
(2) 選擇支付方式的分頁改版設計，讓用戶在結帳頁可以直接選取支付方式，不需要再往下
這個乍聽起來，第2點，設計和開發成本就比較高，於是團隊決定，先試試看第1點，觀測是否成功，若看到支付率提升，我們就會更有信心，完成第2點設計，把我們認為完整的優化設計，呈現給用戶。
(但這不是每個案例都適用，取決於你的方案是否可以被拆分，一小步一小步的試驗)
驗證(Validate)
驗證產品的改動是否帶來價值
這個階段是普遍運用A/B testing的時機。
在開發測試完成後，來決定新功能(改動)是否能夠上線的重要決策工具。若結果如預期，就會成功上線，展示給全部的用戶，若不幸地，結果不如你想像，就得思考，你的改動是否太小，用戶感受不到差異(當你的主要指標無顯著結果)，或是改動與用戶需求不符，所以表現背道而馳(當你的主要指標是顯著的相反結果)？
啟發(Inspire)
啟發下次的設計迭代想法
運用A/B testing產品設計的迭代過程，其實挫折蠻多，有時10次實驗，能夠成功(上線)1次，就算很不錯了！但好在公司文化著重在實驗之中是否有所 “學習”，所以在每次實驗週期結束後，團隊都會聚在一起，聊聊自己看到的有趣用戶行為變化或是洞察，有時與原本我們的預期天差地別，但引領我們提出更多問題，也帶來更多迭代方向的可能性！
每個改動，一定都要用A/B testing測試才能上線嗎？
這得看組織文化，像我們公司對於產品的改動，不管是用戶有感或是單純技術的改動，都得透過A/B testing觀測，才能決定上線與否。我曾經看過一個實驗，是在頁面中，加上幾個分隔線，我心想:「竟然連這種小改動都要做實驗！」可見公司秉持A/B testing的實驗文化。
從這幾年的經驗，我自己也感受到A/B testing對於產品設計過程的好處和弊端。
其中的好處，我個人很有感的是…
科學做事，少點”我覺得”
以前在廣告公司做網頁設計，改稿是日常，常常會有來自各個利益關係人的 “我覺得….”(客戶、老闆、專案經理….等)，當他的 “我覺得” 和我的 “我覺得” 衝突的時候，就需要透過無數的review和談判會議解決，達成共識。
而A/B testing的運用，讓更多想法和意見，可以被客觀的衡量，少了hippo (highest paid person’s opinion)一聲令下的 “我覺得”，少了 “要聽你的”或 “聽我的” 的討論，透過實驗比較哪個產品改動才是更貼近用戶，節省溝通成本，客觀的進行決策。
但A/B testing的導入，也讓我感受到了些弊端…
產品處處都在A/B，無人知曉真實面貌
當一個頁面各個不同區塊，都在做A/B實驗時，可以想像這個頁面有多少種不同的排列組合。常常在產品功能走查的時候，今天發現了這個新功能，但下週再來回顧的時候，又不見了，這時候上到實驗紀錄的網站，才知道原來我是 “lucky user”，看到了那個新功能，但因為效果不佳，就停止實驗了。也因為這樣的狀況，常常會讓其他產品團隊對於產品真實的樣貌，一頭霧水，除了到實驗紀錄網站查詢之外，相關團隊之間保持聯繫，也多少能夠改善這樣的狀況。
事事都要觀測，往往容易成迭代時間的延長和資源的耗損
一項A/B testing至少進行7天，多則數個月之久，有時候，實驗跑完了，效果不佳，再度回到起點，這種挫折感實在巨大…我們團隊曾經花了大概半年，在實驗一個頁面的redesign(單純頁面設計調整，功能不變)，經歷了3–4次的實驗過程，每次跑實驗都像是在賭博一樣(笑)。
所以我們在設計時，盡量能夠以 “小步快跑”來進行，把設計改動，切分成小規模，進行A/B testing，慢慢實驗到我們認為理想的版本，但有時候失敗了，還得埋頭思考，哪裡需要調整，重頭來過。
是科學還是迷信？A/B testing不是唯一真理
實驗結果，不是每次都盡如人意，有時候還會讓人百思不得其解，譬如：每個行為指標都表現得很好，為什麼訂單就顯著掉下來了？除了調研盤查數據表現，這時候也可以考慮導入質性研究，跟用戶聊聊，這些改動對於他們的影響，洞悉這些數字背後的原因和動機，或許就意外發現產品的機會或bug(誤)。
乍聽起來，A/B testing弊多於利？
A/B testing在我看來，還是非常具有價值的工具，帶領我們科學客觀的洞悉產品改動，讓設計更貼近用戶，只是運用它在產品設計過程中，很具挑戰，但這些都是有法可解，如同我上述提到的，多跟其他團隊交流、小規模的迭代、整合質性研究…等。
設計師要用什麼樣的心態，面對A/B testing呢？
對於設計師而言，實驗設置和數據分析，看似離我們很遙遠，有時候也會很抗拒，明明這個設計改動對用戶就很有幫助，為何還要這麼麻煩的進行實驗，但想想其實這些都是用戶使用我們的設計時留下的軌跡，是傳達給我們的訊息，反映著我們提供給他們的設計是否具有價值、是否幫助了他們？ 當我這樣一想的時候，就充滿了動力，想好好利用這樣的工具，理解用戶傳達給我們的”暗語’。
慶幸身在擁有”A/B testing”資源的環境中，團隊內都有實驗大使，也會定期都會舉辦A/B testing的學習講座和團隊分享，強化實驗精神，說真的在這樣的環境，自動就被“催眠”許多A/B testing的知識(懶學生模式)。
透過這樣的媒介，我能夠搜集、量化用戶聲音，當設計改動在實驗數據中達到異常好的效果，那種成就感，是比一位用戶說”很好用”，來的強烈許多！
若此時你們的團隊跟我一樣是如此倡導A/B testing文化，希望你也與我一樣樂在其中！
反之，若你們的團隊還沒有導入這樣的流程，可以觀察產品和公司資源，若覺得合適，非常鼓勵你當個倡議者，鼓吹實驗精神，幫助產品團隊更客觀科學的做決策！
