01 A/B測試 A/B Testing
A/B測試可用來比較同一設計的兩種不同版本,從統計結果找出哪一種較能達到預定的目標(註1)。
A/B測試是一種最佳化的技巧,可用來比較同一設計的兩種不同版本,找出何者較能達成公司目標(註2)。首先是將不同使用者隨機分成兩邊進行A測試和B測試,累計到統計上具代表性的樣本數後,根據測試結果,就可以決定哪一種設計較接近預設的目標。
舉例來說,你的目標是增加免費試用某個線上服務的註冊人數,網友可能會因為很多不同的原因而沒有註冊:註冊表格太冗長?擔心隱私權以及你會如何利用他們的資料?希望在註冊之前先了解收費標準?你可以針對這些問題在介面做一些小修改,找出每個問題的答案,然後進行A/B測試,看看那個版本能吸引較多人註冊。
例如,在上述的例子中,你可以設計幾次測試來比較:
※ 服務條款不同的輔助說明設計,即引導使用者並使其放心填寫的說明文字(遣詞用字、字數長短、字級)。
※ 表格設計(多少個必填欄位)。
※ 不同的按鈕設計,鼓勵使用者在網頁上採取行動(位置、大小、色彩、按鈕上的文字)。
A/B測試雖然可以用來衡量哪一個設計的結果比較好,但是無法協助你了解為什麼使用者偏好某一種設計,因此不能取代用來評估客戶的渴望、態度和需求的質化研究方法,也無法用來處理像是客戶是否信任你的網站這類較複雜的問題(註3),因此,A/B測試一定要搭配質化方法,才能進一步了解客戶真正的動機和需求。
註1: A/B測試源自傳統的廣告郵件(DM),將同一份廣告的兩種不同版本寄給不同人,再來了解哪一種版本的回應率較好。
註2 :Nielsen, Jakob.“Putting A/B Testing in Its Place,” 2005, http://www.useit.com
註3: Kahavi, Ron, Randal M. Henne, and Dan Sommerfield.“Practical Guide to ontrolled Experiments on the Web: Listen to Your Customer Not to the HiPPO.” Proceedings of the 13th ACM SIGKDD, 2007.
A/B測試:eBay個案研究
A/B測試可以導出不同的假設和產品的方向,重要的是必須隨時間進展不斷地實驗,不能假設過去觀察為真的經驗值在未來一樣有效。eBay在2010年進行了一系列關於圖片大小的實驗就是很好的例子。
eBay研究人員在幾次測試後普遍發現,買家在頁面頭版能夠看到的商品越多,越不需要捲動頁面,點擊率便越高。根據這個假設,研究人員設計了一個圖片尺寸的A/ B 測試,希望能夠驗證當圖片越小、每頁能夠顯示的商品越多時,點擊率會因此提升。
令研究人員意外的是,跟較大的圖片(A測試)比起來,較小的圖片(B測試)表現未如預期好。經過深入調查和後續的測試之後,研究人員發現結果正好相反,即使頁面頭版顯示的商品較少,但是買家對較大的圖片仍然比較有反應。eBay於是迅速根據實驗的結果,在全站都改放較大的圖片。
資料來源|Robin Chiang, eBay, Inc.
37 經驗取樣法 Experience Sampling Method
設計師透過經驗取樣,搜集參與者在收到信號或於固定時間即時自我描述的行為、互動、想法或感受。
經驗取樣法在設計界行之有年,但其實是源自社會科學(註1)。這個方法在設計研究的探索和衍生階段十分有用,而且通常伴隨著日誌或照片研究。新的科技和軟體賦予這個方法更多的可能性和彈性。
經驗取樣要求參與者在接到信號時,通常是透過裝置提示,記錄下特定的事項。以前通常是利用呼叫器,所以這種方法又稱為「呼叫器研究」(beeper study)。現在的科技帶來更多發送信號的方式,像是利用智慧型手機的應用程式來設定鬧鈴,提示參與者記錄或發送訊息。
設計研究人員所關心的行為、互動、想法或感受,必須在事前溝通清楚,並讓參與者記錄在事先準備好的格式中,通常是日誌或日記。記錄的項目可能很廣泛,像是「記錄下你現在的感受」;或很明確,像是「列出你目前正在使用的通訊產品」。
日誌的設計必須容易攜帶,而且方便記錄研究所需的事項。
通常,經驗取樣會要求參與者利用簡單的素描或照片,記錄下周遭環境及相關的物品。若是使用照片,必須注意影像與文字如何配在一起。以前很簡單,只需要一台拍立得和一支筆便能解決這個問題,但對數位影像來說就比較困難一點。不過,智慧型手機的新科技已經可以做到同時記錄(和傳送)文字與影像,或以聲音取代文字。
經驗取樣是設計民族誌的一種形式,將傳統費時的實地觀察,濃縮成選擇性搜集行為、互動、想法或感受的樣本。如果做得好,這些樣本可以代表整體的經驗,提供設計師相當完整的概觀,進行各式的設計研究。
註1:Larson, R., and M. Csikszentmihalyi. “The Experience Sampling Method.” New Directions for Methodology of Social and Behavioral Science 15 (1983): 41-56.
80 利害關係人分析圖 Stakeholder Maps
利害關係人分析圖有助於用視覺化的方式將設計方案中的關鍵組成分子連結起
來,針對以使用者為中心的研究和設計發展去架設舞台。
隨著設計過程展開,在規劃、釐清和定義階段,最重要的工作就是要找出哪些人是和設計結果利害相關的重要組成分子。利害關係人分析圖就是為了達成這項目的,提供圖像式的關係圖,讓設計團隊在規劃使用者研究活動時做為參考,並引導團隊在整個方案發展過程中,與利害關係人進行適當的溝通。
利害關係人分析圖一開始通常是推測圖,由設計團隊用腦力激盪方式找出在設計方案界定的領域內,所有利害攸關的人士。這個階段的重點是滴水不露。除了找出終端使用者之外,還必須找出哪些人可以從方案中獲利,哪些人握有權力,哪些人可能受到不利影響,甚至哪些人可能阻撓或破壞設計結果。
利害關係人可以用一般角色(學生、運送駕駛、護士)、專業角色(執行長、專案經理、外科主任),或真實人物(辦公室經理羅伯、住院醫師琳達)來界定。一開始可以簡單製作,把角色貼在白板、卡紙、筆記本或紙張上面,組合成一張名單或草圖。接著將草圖變成更有組織的結構,盡可能顯示上下階層,以及角色或人物之間的關係。可以用大小、線條和遠近等方式將關係視覺化,努力建構意義並將它清楚傳達給設計團隊。
純就理論而言,經過不斷修正的利害關係人分析圖,應該能夠推斷出真正的組成分子,也能讓他們之間的工作流程和關係變得更加清楚、明確。隨著草圖逐漸發展並取得共識,最後通常會以綜合性的圖解呈現。不過,利害關係人分析圖也可以採用其他正式或非正式的形式,結合文字、照片與繪圖。也就是說,並不存在某種正確的表現形式,只要能夠指出關鍵角色和他們之間的關係,滿足這項目的即可。
99 奧茲巫師互動模擬技術Wizard of Oz
在奧茲巫師這項互動模擬技術裡,是由一名研究人員(「巫師」)在幕後模擬系統反應,讓參與者和栩栩如生的系統進行互動。
奧茲巫師(WOz)技術這項方法,是要引導參與者,讓他們以為自己正在和某個系統的工作原型進行互動,但其實是由一名研究人員在幕後扮演系統代理人。由於參與者看不見研究人員(也就是「巫師」),因此不必建造可以實際運作的系統,就能由研究人員攔截和塑造參與者與「系統」之間的互動。這項方法可以在投入經費製作原型之前,讓使用者體驗設計中的產品或介面。也可提供一個框架,評估參與者對於新方法的開放程度和投入意願,以及是否願意在科技創新與突破的邊境進行探索和發現(註1)。
安排研究會議時,要把參與者和扮演「巫師」的研究人員安置在不同的場地。務必要讓研究人員可以觀察到參與者的反應(透過錄影機或螢幕共享軟體),這樣才能做出適當而即時的系統反應。在設計的初期階段,巫師會模擬系統的大多數行為,從中汲取洞見,提供資訊引導團隊做出最後的設計形式。隨著介面不斷改進,需要研究人員/巫師出手干預的情況也越來越少,通常只需要能讓過程持續進行,同時填補現階段所能提供的實際功能和理想中的系統功能之間的落差即可(註2)。
進行過程中,巫師還可以扮演不同角色,模擬不同行為,包括:模擬系統智慧的控制員( c o n t r o l l e r ) , 修正程序以及推翻系統或參與者所做決定的監督員( s u p e r v i s o r ) , 以及模擬感官資料讓理想中的體驗感受臻於完美的調節員(moderator)(註3)。不過,模擬的可信度還是取決於巫師的行為能否在時間點、模式和系統邏輯上保持一致(註4)。
當你需要評估人們使用產品的感受以及可能會以何種方式使用時,便可採用奧茲巫師模擬技術。這是一種值得推薦的方法,可以在實際投入時間和資金製作原型之前使用。尤其適用於尚未存在既定設計模式的數位應用程式和解決方案(例如,擴增實境系統,以及無所不在的運算)。這項方法是一種彈性十足、反覆運作的技術,可以在專案初期的探索和構思階段,為設計構成發揮引路和帶領的功能,也可以在後期階段派上用場,做出更適切的結論和總結性評估。
成千上萬個曾經和動畫角色魁西機器人(Qua s i the Robot)互動過的民眾,都不知道原來是有一名真人演員,在互動現場後面,透過「引導表現介面」(Guided Performance Interface,GPI)軟體控制機器人的動作。這個介面可以讓非技術人員引導魁西做出動作,吸引並延長民眾(特別是小孩)的注意力。機器人魁西是一個精采範例,把人工智慧和人類遙控技術結合到出神入化的程度,創造出可以讓人愉快投入的體驗(註5)。
註1:IBM華森研究中心(IBM Thomas J. Watson Research Center)的約翰.「杰夫」.凱利(John F.“Jeff"Kelly),在1980年首先提出「奧茲範式」( O z Paradigm)一詞,用來形容他在約翰霍普金斯大學撰寫論文時開發出來的方法學。隨著這套方法在人因工程、實驗心理學以及使用性工程等領域日益普及,名稱也跟著改變,靈感是來自1939年的米高梅電影《綠野仙蹤》(The Wizard of Oz),在這部電影裡,有位平凡人躲在簾幕後面,利用科技說服大家相信,他是一名法力無邊的全能巫師。參見:Kelly, John F. “An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications.” ACM Transactions on Office Information Systems 2, no.1 (1984): 26-41.
註2:參見註1。
Dow, Steven, Blair Maclntyre, Jaemin Lee, Christopher Oezbek, Jay David Bolter, and Maribeth Gandy. “Wizard of Oz Support Troughout an Iterative Design Process.” Pervasive Computing (October-December 2005): 18-26.
註3:參見註2。
註4:參見註1。
註5:Patel, Seema, et. al. “A Guided Performance Interface for Augmenting Social Experiences with an Interactive Animatronic Character.” Proceedings of 2006 American Association for Artificial Intelligence, 2006.