[CUI 101] 語音設計的原形測試方法
本文適合（1）進入 UX 領域 1~3 年的 Designer（2）喜歡探索和了解新領域的 Geeker（2）開始進行 CUI/VUI 設計的 Anybody
在先前的語音體驗設計連載「Conversational UX 系列」，與大家分享了從最了解語音設計開始，到真正進行語音設計的過程總共五篇，對語音設計進行了比較系統化的說明。
但相信大家看完後，仍然多少會對如何獨自開始進行語音設計項目，或帶領團隊從發想到測試，完整的執行一個語音設計項目感到疑惑。
因此後續 Nathan 也會結合在設計天貓精靈語音產品的相關經驗，把語音設計過程中的重要環節，單獨拿出來與大家聊聊。
用戶測試是產品開發過程中非常重要的一環。如果從用戶體驗的角度出發，CUI 類型的產品在用戶測試階段，其實與傳統產品有許多相似之處，但同時也存在部分差異。
這次的文章 Nathan 將向大家介紹在 CUI 設計中，常用的原型測試方法，包括如何挖掘用戶意圖、如何驗證設計方案以及如何衡量測試結果。透過這些原形測試方法，能夠幫助設計師或團隊在開發的早期階段，快速執行用戶測試，幫助語音產品在早期階段能更快的試錯。
CUI TESTING 的執行策略
與所有產品開發一樣，但些微有差異的是，進行 CUI 項目時，強烈推薦在早期階段就開始進行大量的用戶可用性測試。
原形測試的目的是保證設計者清楚用戶的使用場景，使所設計出來的產品，能讓用戶在場景中被正確的使用。原因在於我們並不是產品的目標用戶，很多需求和設計方案是產品設計人員自己想出來的，常常在討論方案的時候總是說：“ 用戶想要…”、 “我覺得…”、 “如果是我，我會…”，透過這些話術來獲得團隊的或項目組的認可。
雖然真正進行設計時，還是會依據一些經驗與設計法則，但這些都只是未經驗證的主觀猜測而已，無法準確的評估設計方案的優劣，這往往導致觀點對立，僵持不下。
尤其在 CUI 這種沒有可視界面的交互方式，單純文字的溝通容易讓大家產生不一樣的理解。
所以為了了解真相（用戶到底會怎樣使用產品），我們要找到我們的目標用戶並向他們學習（觀察他們如何使用產品），這樣才能使團隊盡快對設計方案達成一致並積極改善產品。
充分利用現有資源
原形測試階段，首先要關注是否有和你正在開發的產品相類似的先例（即使實現方式不同）。通過已有產品事先了解哪些是有用的，哪些是無用的，對於語音產品的測試成果非常重要。
通常透過已經存在的交互式語音應答系統（IVR, 電子語音答錄）。可以發現這類已有的類似功能，目前是如何運作的，以及對應的數據反饋，可以作為後續 CUI 項目切入類似領域的大好機會。
以虛擬助理 Cortana 為例，為了獲得靈感，微軟的設計師採訪了現實生活中的私人助理。設計師發現，當私人助理不理解指派的任務時，他們通常會尋求幫助。因此，微軟的語音設計師認為， Cortana 也可以在必要時尋求幫助，正如她的人類同行一樣。
此外，現實中的私人助理通常隨身攜帶筆記本，上面記著與服務對像有關的內容，所以使用 Cortana 時也能觀察下，其實也擁有了類似的筆記本。
進行 CUI TESTING 時的特殊考量
進行 CUI 的測試時，如果用戶的使用不單只依賴語音時，建議不要向用戶透露被測試的產品有語音交互功能。
更需要關注的，是用戶在產品體驗的過程中，與各個觸點的交互行為，如產品包裝、說明書等。在測試過程中需要重點確認一件事：用戶是否知道他們可以與系統進行對話？他們知道怎樣開始對話，以及何時開始對話？
如果系統允許語音交互的能力，但用戶卻沒有在我們所設想的階段進行語音交互時，明確的表現了這個開始對話的提示一點也不明顯。許多測試結果可以看到用戶在事後評論說，“要是我在那個地方就開始說話，事情就簡單了！” 顯然，這個系統在語音的引導設計上還需要做一些改進。
另外常用於 GUI 測試的方法，常常會用 Think Aloud 這種，讓用戶敘述他們正在做什麼。但這種測試方法對於一個真實的 CUI 系統而言，明顯行不通。
CUI TESTING 測試方法的選擇
在目前的語音行業中，通用的一些 CUI 測試工具包括 對話遍歷測試、系統質量保證測試、載荷測試、可用性測試、綠野仙踪測試、可用性走查、CUI 評估啟示（CRT）、問卷評估、場景錄音調取、對話日誌調取等。
這些評估工具與方法，被應用於 CUI 項目在開發生命週期的不同環節，其中大多數被應用於設計和評估階段。問卷評估、場景錄音調取、對話日誌調取方法，更多時候會被應用於項目前期，以及上線後收取數據的 CUI 評估。
綠野仙蹤
目前業內最有名也最普遍使用的是 Wizard of OZ, 綠野仙蹤法
“綠野仙踪不僅是一部經典的電影，也是一種幫助你確認產品設計的方向是否正確的工具”。綠野仙踪測試是 CUI 測試工具中最常用的一個，適用於需求挖掘、設計、測試和分析階段。
綠野仙踪法，在亞馬遜 ECHO 產品系列的 VUI 設計中被引入，成為經典的測試方式。成功幫助 Alexa 進行 3 個主要維度的設計和優化：交互形式、響應速度、VUI 的語言情感傾向
亞馬遜 Echo 的實驗操作流程大致如下：用戶在單向實驗室中對電腦做出語音指令，單向鏡後的主試員（巫師, OZ）人工返回相應結果；實驗結束後，實驗對象需要填寫一份滿意度問卷，並寫出他們喜歡怎樣的回复。
每次的功能測試組控制：大約會有50人次進行同樣的測試，在測試過程中，回複方式和回复時間作為組間區分變量，直接驗證用戶對回複方式、回复時間及對語調的喜好傾向。
這種方式的好處就在於，能不依賴算法，已低成本的方式完成語音模擬測試。
有興趣了解綠野仙蹤的使用方法，可以參考上面鏈接
當你想了解自己產品語音部分的表現，進行綠野仙踪測試（Wizard of Oz Experiment）和原型測試（Prototype Testing），就非常有必要了；
總體上，原型測試更優，但是綠野仙踪測試可以在設計階段就評估語句措辭。
而 CRT 和可用性走查法可以評估 CUI 的整體體驗水平，並且是專家從用戶角度來進行評估，如果說前一階段的測試是為了驗證流程是否走得通，那這個階段的測試結果要求更精確以發現更多可用性問題，讓語音交互界面變得好用。
另外在語音項目預發布階段時，可以使用對話遍歷測試、識別測試、負載測試等，進行一些通用性與是否存在 Bad Case 的典型測試問題。
上線後的效果評估，則可以應用數據回收工具進行以下分析：意圖達成率、交互流失率、有效使用時長、語音打斷次數、需要與 GUI 的轉換、BUG（無應答、無匹配內容、延時）、完整呼叫記錄等。與 GUI 的數據迭代和分析過程，其實差異不是特別大。
常態性 CUI 效果評估
要建立常態性的評估 CUI 效果，一般需要三類數據共同輔助：對話日誌（埋點數據）、使用音/視頻記錄、滿意度問卷。
一般會先從日誌開始，當一個潛在的風險（可能是需求不匹配、常態性錯誤）等，都能通過日誌數據被識別出來，也就鎖定了問題。接下來調取事發時刻的音/視頻記錄，用以分析 CUI 在這個過程中究竟是怎麼表現的，基本可以定位問題並分析原因；如果發現一些問題需要追問就可以用問卷或者訪談來補充和驗證自己的假設。這樣的方式相對高效、充分地利用每一部分數據，各數據之間形成互補。
透過日誌或視頻記錄來進行效果評估時，需要記錄的關鍵要素包括：
①用戶如何進入一段對話（CUI引導、入口設計）；
②哪些對話輔助效果突出任務流暢（CUI主動性、內容有用性）；
③什麼時刻用戶感到迷茫或不耐煩（CUI結合反饋形式、CUI內容設計）；
④任務出錯時是否能即時修正（CUI 防錯機制）。
本篇是 CUI 101 系列的第一篇，提供一些進行語音測試時，方案上的一些經驗與思考。如果有興趣的話可以在透過關鍵字進行搜索，了解網路中相關的介紹。
如果你對於 CUI 設計也有不同的看法，或者發現 Nathan 的文章中有錯誤的部分，也歡迎你隨時讓我知道。有些名詞與定義，可能都是目前這個領域中還屬於比較模糊的部分，部分比較敏感的內容，也礙於保密協議問題無法公開。
這是一個隨時都在變化，隨時都在進步的領域：）
如果你喜歡我的文章，請給我 1~4 個 Claps ，如果你想要看到更多 Nathan 分享更多關於 Conversational UX 的內容，請給我 5~以上的 Claps，對這個領域有興趣的話，也可以隨時騷擾 Nathan 關於 CUI 的資訊囉～
See ya~
-Nathan
最後想知道大家感興趣 Nathan 分享什麼主題呢？是繼續語音 CUI 設計方法？還是在阿里巴巴中的設計生活？希望大家可以留言給 Nathanm，讓我知道大家最感興趣的主題喔！
