本文由 Nikki Anderson 發(fā)布于 Dovetail。Nikki 是一名用戶研究領導和教練，擁有超過八年的經(jīng)驗。Dovetail 是用戶洞察研究數(shù)據(jù)存儲和分析平臺，幫助用戶研究員和團隊更好的產(chǎn)出洞察。

無主持可用性測試（Unmoderated Usability Testing）這種調(diào)研方式有不少爭議。如果設計的不好，非常容易出錯。但是在特定情況下，它能成為項目的救命稻草。

大家可能對無主持可用性測試抱有懷疑：發(fā)布沒多久你就會得到一堆低質(zhì)量用戶反饋，讓團隊頭疼于如何過濾、分析這堆混亂的數(shù)據(jù)。

現(xiàn)實是在用戶研究員的日常工作中，項目的時間線很緊，團隊需要簡化用戶研究方法，加快速度得到結(jié)果。當時團隊有好幾個研究需要完成，得同時進行。我們嘗試了無主持可用性測試后，發(fā)現(xiàn)它并非之前想的那么糟。畢竟，用戶研究員不是唯一一個事情太多時間不夠的人。

有很多設計師和產(chǎn)品經(jīng)理嘗試進行全面的用戶研究，但沒有這個時間和條件。無主持可用性測試能讓團推快速拿到結(jié)果，同時仍然能從用戶那里收集有用的數(shù)據(jù)。

什么是無主持可用性測試？

當團隊有一個需要調(diào)研的問題，用戶研究人員把這個問題設計成一個帶有問題的任務發(fā)布給參與者，讓他們自行錄制來回答問題或完成指定任務。很多用研對無主持測試不感冒，是因為測試期間沒有主持人。那么無主持測試就對受訪者的要求很高。

用研必須招募到能夠把想法口述出來 (Think out loud) 的參與者，理解任務，理解如何使用設計原型，對問題做出反饋，最后完成錄像。

無主持測試如果設計完善，能給項目帶來很多益處：

• 在短時間內(nèi)獲得大量反饋：從周五發(fā)出的調(diào)研，周一就可以獲得理想的數(shù)量。測試主要在周末進行，幾乎不需要投入主持的精力
• 更低的調(diào)研成本：因為非主持測試需要的人力和參與度更少，10-20 分鐘就可以完成一份調(diào)研，通常比主持測試短得多
• 多樣化的參與樣本：遠程線上進行，更多人可以參與
• 簡化研究過程：更快獲得結(jié)果，縮短調(diào)研時間線

非主持測試也有一些缺點：

• 團隊無法給參與者提醒、解釋任務、或詢問他們?yōu)槭裁醋鞒瞿硞€行為，因為沒有主持人實時提問
• 參加測試門檻很低，團隊可能會遇到什么反饋都不分享 (think out loud)、只完成任務為了獲得“報酬”的人。這就導致無用數(shù)據(jù)，如果參與者沒有分享他們的想法，團隊就只會得到?jīng)]有解釋的行為數(shù)據(jù)
• 技術問題得不到解決，比如參與者未正確錄制，數(shù)據(jù)就浪費了
• 如果參與者混淆或誤解任務，調(diào)研員無法回溯或解釋，就會導致不準確的結(jié)果

無主持測試最大的風險是得到無用或混亂的數(shù)據(jù)。但如果我們仔細篩選用戶，在合適的項目節(jié)點選擇使用無主持測試，我們還是可以減少風險獲得我們想要的結(jié)果。

什么樣的項目適合無主持測試？

• 設計原型相對簡單、直接，最好有明確的用戶路徑來完成一個任務
• 收集小的設計組件或設計更改的前后對比（類似 A/B 測試）
• 收集初步反應，例如人們看到一種設計會做出什么樣的第一反應
• 推斷影響一個小樣本的問題如何反映到更大的樣本
• 獲得用戶對品牌設計風格，價值和調(diào)性的反饋

以下情況我們還是需要主持人，而不是簡單粗暴的用無主持測試替代：

• 對一個設計或話題要求有深入反饋或理解，因為無主持測試的任務或問題需要很簡單，測試期間無法進行后續(xù)跟進
• 產(chǎn)品或原型較復雜，有許多不同的路徑，可能會讓用戶感到困惑或需要很長時間來完成
• 測試一個非常早期的想法，比如原型有局限性，有些部分還不能點擊
• 參與者是自己主導整個流程，沒有有主持人就很難在合適的場景主動表達他們的感受

無主持用戶測試的最常見目標需要很集中，且流程需要短：

• 找出簡單原型的可用性問題
• 產(chǎn)品問題的可能導致的更大影響
• 了解用戶是否可以找到信息或完成某個操作
• 衡量參與者是否理解產(chǎn)品的重點和價值

如何創(chuàng)建一個無主持測試

1. 撰寫非主持任務和問題是最有挑戰(zhàn)的部分，也是測試成功的關鍵。如果發(fā)送的任務或問題撰寫不當，參與者的回答可能會帶有偏見或引起混淆
2. 直接告訴參與者需要他們完成什么，或不希望他們做什么
3. 設計合理的調(diào)研問題或任務需要給參與者背景和上下文，為什么他們需要這個產(chǎn)品，在日常生活的什么場景中會使用它
4. 如果用戶需要在調(diào)研中輸入日期、地點或特定數(shù)據(jù)，也需要明確的提示他們
5. 當要求參與者完成任務時，確保他們有一個明確的“結(jié)束”，讓參與者明確任務是否成功完成并且反饋給團隊
6. 避免使用帶有偏見或引導性的語言，尤其是界面上顯示的文字。例如，如果希望參與者點擊“注冊”按鈕，就要避免在任務里誤寫“登記”按鈕
7. 將較艱巨的任務分解成幾個不同的步驟
8. 反復提示參與者在錄制整個過程中說出自己的思考過程

我們可以來看一些案例，如何設計無主持測試，以及要避免什么

例一：Brand Jeans（虛構(gòu)的服裝公司，b2c)

用戶目標：瀏覽并購買一條平均價格為50美元左右的牛仔褲

不完善的測試任務：找到你尺寸的黑色牛仔褲

完善的測試任務：你正在尋找一條新的 Brand 牌牛仔褲。請前往 brandjeans.com，去購買一條牛仔褲，你的預算是 50美元左右。    

小貼士：如果給用戶一定的自由，讓他們?nèi)ケ容^不同類型的牛仔褲，并提供一個參考預算（50美元），他們可以更自然的完成任務給出日常瀏覽網(wǎng)站的路徑

例二：Stay Here（虛構(gòu)的酒店 ，b2b)

用戶目標：將酒店場地和房間的照片上傳到 Stay Here 平臺

不完善的測試任務：您想將酒店照片上傳到網(wǎng)站。登錄平臺，點擊上傳照片按鈕，上傳三張照片，點擊提交按鈕，告訴我們你是否能完成任務。

完善的測試任務：你想在你的StayHere頁面上添加一張新套房的照片。請點擊平臺鏈接并將提供的照片上傳。提示：您需要準備幾張照片。

第一個任務過于具體，并給出了太多線索。更好的測試設計應該給出合理量的信息，同時告訴用戶他們需要做什么，包括要準備什么：例如提供幾張供他們上傳的照片。

綜上，我們在設計任務時需要考慮：

1. 任務背后的上下文
2. 平衡任務指令的具體與寬泛程度
3. 在合適的節(jié)點為參與者提供有用的信息來完成任務
4. 以行動為導向的任務設計，結(jié)論需要能夠讓團隊有明確的行動目標
5. 記得在發(fā)布測試前進行一兩次模擬測試，來排除潛在流程問題

如果研究不需要過多解釋復雜的流程或細節(jié)，參與者也不會對任務產(chǎn)生太大的困惑，那就非常適合做無主持測試，來迅速獲得用戶的反饋和產(chǎn)品的改進方向。