反覆測試
在設計過程中,使用者研究也可以隨時派上用場。而是要獲得實際使用者的意見回饋,找出有效和可行的部分。越早進行這項作業,效果就越好。
您難以在設計中融入方面的問題,需要外部外部的意見。好消息是,只要編寫一行程式碼,即可快速且輕鬆地取得深入分析資訊,瞭解設計是否適用於使用者。
取得意見回饋,瞭解對話方塊是否正常運作
使用 Oz 實驗的精靈
這就是為什麼?綠野仙蹤 (WOZ) 實驗的導演名稱是《奧茲的精靈》的導演,他們認為這是一個人在幕後,有男子拉長的控向。
綠野仙蹤的精靈是什麼?簡單來說,這是測試原型設計,而不必實際開發軟體。WOZ 原型可用於評估設計功能、達成使用者目標的能力,以及改善整體使用者體驗 (UX)。WOZ 實驗的目的是在實驗過程中看起來像是實際體驗,而非軟體本身,而是有人物 (稱為「精靈」) 模擬人物角色在生產環境中的行為。參與者可能並不知道自己是否與窗簾下方的精靈互動。
為什麼要這麼做?WOZ 原型設計的一大優勢,是無須建構應用程式即可測試設計。WOZ 實驗是用於語音測試的最小原型產品 (MVP)。執行起來相對簡單,而且也不需要花費額外心力。這個原型可能很簡單,可利用日常物件來代表設計的各個部分,也可能是能執行部分工作 (但並非全部) 的工作模式。當然,原型設計越實際,意見回饋的品質就越高。但請謹慎選擇:您願意分配多少時間?原型的「真實」價值是否值得?
如何執行可用性測試
1) 快速且簡潔的 WOZ 實驗
2) 標準 WOZ 實驗
請使用 Actions on Google Developers Console 中的 TTS 模擬工具,模擬人物角色的提示,藉此取得最符合個人需求的體驗。下載音訊,隨時享受隨選音訊。
這個版本需要下列四點:
- 對話腳本,提供有關每位使用者回應後的意見內容。使用高階流程 (或簡化版流程) 非常適合使用此功能。
- 已下載所有人物角色語音提示的音訊。這個檔案名稱可協助您快速識別要播放的正確檔案。
- 某人將玩「使用者」。表示某位動作的使用者不熟悉您的動作。
- 有人要玩「精靈」。這會讓對方非常熟悉您的操作。
讓精靈播放動作問候語的音訊開始對話,例如「歡迎使用啟動器啟動所有 Google I/O 專屬功能。節慶活動進行中!你是幸運參與者嗎?精靈會等待使用者做出回應,希望與同義詞 (是「是」或「否」) 做出回應。使用者做出回應後,精靈會快速查詢高流程流程,以便判斷接下來要播放什麼內容,然後找出並播放正確的音訊檔案。
3) 標準可用性實驗
當然,在您開始建立動作後,通常會使用 Actions on Google Developers Console 中的動作模擬器進行測試。邀請朋友、家人或同事進行測試!
無論使用哪種實驗,請務必: | |
---|---|
朗讀 | 你的目標是更新設計,反映真實使用者需求,因此希望 WOZ 原型盡可能貼近現實。紙張的品項未必是實際的對話模式,也不一定能流暢地對話,因此請確保使用者能聽到您的提示,並說出自己的回應內容。 |
記錄工作階段 | 請先取得權限以錄製會議,以便你返回並聆聽。記下工作階段期間出現的問題。 |
徵求意見回饋 | 要求使用者用自己的方式描述自身體驗。為何覺得成效不如預期?有什麼驚喜嗎?滿意嗎?切記,重點在於使用者的行為,而非他們的觀點。 |
後續課程內容
透過 WOZ 實驗,您可以瞭解使用者如何與您的設計互動。您可能會發現,使用者採取不符合預期的做法,所以必須調整設計以符合他們的需求和期望。
收益:聚焦於設計的可用性,而非使用者的意見。根據使用者行為反覆改進,如果時間允許,請重新測試。
請思考哪些地方 (以及您可以如何改善對話方塊): | |
---|---|
自然對話 | 注意使用者自然搜尋資訊的方式。他們是否覺得只能在簡短簡短關鍵字語句中對話,還是比較能夠交流?和員工角色交談時,他們會感到不悅或毫無自信嗎?這種流程是否讓使用者可以一次提供一種資訊,還是必須在同一句話中提供多項詳細資訊? |
使用者混淆 | 找出使用者感到困惑或不確定該表達什麼意思。請查看先前的提示,瞭解該如何進行說明。行動號召是否清楚? |
非預期語音 | 使用者可能會說你出乎意料的內容,請記下來,並在設計中新增對策。 |
有挫折感或令人反感的跡象 | 這通常表示互動的互動時間過長。請查看您的提示,看看是否比較簡潔。有沒有可以省略的詳細資料嗎? |
觀察誰最常發表 | 使用者是否覺得自己能夠掌控對話內容?如果不是,該如何變更? |
如何測試動作
完善的測試對於開發優質軟體及提升使用者滿意度至關重要。