編輯導語:自主式可用性測試對於使用者研究來說十分重要,本篇作者分享了編寫自主式可用性測試指令碼的具體方法思路,根據工作經驗總結整理出幾個設計自主式測試指令碼的訣竅和誤區,一起來學習一下吧,希望對你有幫助。
“ 在沒有訪談主持人的情形下,我該怎樣才能引導受測者完成整個測試流程呢?”
作為遠端使用者測試平臺,以往我們向亞洲區的使用者體驗研究員介紹自主式可用性測試(unmoderated usability testing)時,時常被問到這個問題。
在歐美的使用者研究行業中,自主式可用性測試在過去十幾年來已發展成主流的研究方法,然而在亞洲地區我們才剛開始起步,對於其可行性難免會產生疑慮。
根據十多年的行業服務經驗,以下整理出幾個設計自主式測試指令碼的訣竅和誤區:
一、測試時長不超過三十分鐘
一般不推薦設計超過三十分鐘的自主式使用者測試,因為在沒有主持人互動的情形下,超過這時長受測者可能會感到無聊或倦怠,進而影響測試結果的質量。
二、「漢堡包法則」
一項自主式可用性測試應該由
「開場」、「任務」和「收尾」
三大部分組成:
1. 上層:開場
在開場中,應該告知受測者接下來的三十分鐘內他們將要互動的產品、產品使用場景以及測試流程。
缺乏使用者訪談經驗的使用者研究員常會輕忽開場白的設定,導致專案參與者在執行第一個任務時便失去頭緒。
典型開場白如下:
請大聲讀出以下說明:
請牢記在同網站或手機軟體互動時,大聲說出您的想法。如果您有任何無法理解或困惑的事,請讓我們知道。
如果您無法找到或不理解目標產品的某些內容,請大聲解釋清楚您希望看到什麼內容,或者透過改變哪些方面來改善它。
想象您正在……
如同常規的使用者訪談,我們想要自主式測試的受測者能夠敞開心胸並保持健談。讓受測者大聲念出開場白和任務指示能幫助他們調整成開放狀態。
2. 中層:任務
如同漢堡肉之於漢堡包,可用性任務是整個測試專案中最精華的部分。
原則上,研究員需要設定五到八個可用性任務,並根據需求在其中穿插量化問題或簡答題。
範例如下:
1)【可用性任務】
您伴侶的生日快到了,您想購買售價¥800 以上的真無線藍芽耳機送給她/他作為生日禮物。
請試著購買一副條件符合且您認為她/他會喜歡的耳機,並在需要付款時停止動作。
當您認為任務已完成時,請單擊「下一步」。
2)【量化問題】
您是否能完成前一個任務?
是 / 否
3)【量化問題】
總體來說,您認為完成這個任務的難度為?
1 分表示「非常困難」 7分表示「非常簡單」。
「一項任務 + 二個量化問題」
是常見的活動組合。
一場三十分鐘的自主式測試中,這樣的組合可以
重複五到八次
。
將任務和問題捆綁的好處是研究員可以在觀察使用者操作行為之餘,一併獲取定性和定量的使用者洞見。
捆綁任務和量化問題(測試編輯器畫面):
3. 下層:收尾
在使用者完成所有可用性任務後,可以讓他們填答「系統可用性量表(system usability scale)」或是「淨推薦分數(net promoterscore)」,作為對產品整體使用體驗的量化評比。
系統可用性量表:
測試結束前,可以讓受測者分享最後的想法或意見。最重要的是,務必讓他們等待
測試
結果完整上傳後
才退出測試頁面。
在大部分的遠端使用者測試平臺,任務視窗會預設指引受測者在退出測試前先等待測試結果上傳。
三、新手編寫指令碼時常犯的錯誤
1. 可用性任務缺乏場景描述
未提及產品或功能的使用場景,導致得出的使用者洞見失真。
2. 文字排版雜亂
內文冗長且編排密集,導致使用者閱讀失誤而執行無效的可用性任務。
3. 單一活動置入太多工
當同一個活動(activity)中陳列超過三個可用性任務時,某些任務可能會被受測者不小心遺漏。儘量將每個任務分散在個別活動。
原文連結:https://mp。weixin。qq。com/s/7Q0C3WSDkQSOa3R48WRfqQ
本文由 @Stan Wang (Userlytics 優思來授權)釋出於人人都是產品經理,未經作者許可,禁止轉載。
題圖來自 Unsplash,基於 CC0協議。