如何編寫自主式可用性測試指令碼?

編輯導語:自主式可用性測試對於使用者研究來說十分重要,本篇作者分享了編寫自主式可用性測試指令碼的具體方法思路,根據工作經驗總結整理出幾個設計自主式測試指令碼的訣竅和誤區,一起來學習一下吧,希望對你有幫助。

如何編寫自主式可用性測試指令碼?

“ 在沒有訪談主持人的情形下,我該怎樣才能引導受測者完成整個測試流程呢?”

作為遠端使用者測試平臺,以往我們向亞洲區的使用者體驗研究員介紹自主式可用性測試(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協議。

頂部