編輯導讀：可用性測試，能夠讓產品經理借助用戶，更加客觀理性地理解產品功能以及交互，并結合測試結果予以改進。本文作者從遠程可用性測試的概念出發，結合案例分享了創建一個有效的遠程可用性測試的具體流程和相關技巧，供大家一起參考和學習。

現在大部分用研的小伙伴，每一次做可用性測試都需要邀請參與者在現場完成任務，觀察并注意他們的行為，然后總結得出結論。沒有遠程進行可用性測試，因為在底層認知內是必須在同一個房間做任何類型的用戶體驗研究才能獲得數據。

現在國外和國內大廠的遠程可用性測試就是很普遍化了。那么我們該怎么找到適合現狀的遠程可用性測試呢。

一、什么是遠程可用性測試？

遠程可用性測試是指參與者和研究人員在不同地點進行的測試。隨著技術創新的推進，遠程測試在實踐中有所增加，在線工具也為遠程測試提供了便利。會話通常通過可用性測試平臺進行（不打廣告，自行百度），它記錄完成測試的人員，收集數據，并生成報告。

遠程可用性測試的好處：

1. 可以更好地找到參與者，因為他們可以不用坐著公交來到公司進行參與，參與者可以在任何他們想要的時間以及他們想要的地方進行測試。
2. 有足夠的定量數據支撐
3. 創建測試和獲得結果之間的時間要短得多，可以非?？焖俚孬@得數據驅動。
4. 開銷-為公司節約成本。不需要包路費或者足夠的送禮品。遠程發個紅包，也能表達感謝之情。

遠程可用性測試的缺點：

1. 總體測試環境和過程的控制較少。例如，如果任務不清楚，就不能在那里更詳細地解釋它，并將其引導正確的方向。
2. 解決方案：為了最小化這些風險，在測試開始時介紹性的講述緣由，以便參與者知道將要發生什么，也請告知參與者測試的目標，并確保他們掌握了所有必要的信息來理解所參與的內容。
3. 遠程測試進行試驗需要確保編寫任務的方式非常清晰。
4. 遠程可用性測試并不比面對面的測試工作量少。它通常需要更多的計劃和更多的交流。因此，要做好相應的計劃，確保你要使用的工具和設備工作正常。
5. 需要給某些可用性測試平臺付費

彩蛋：共享屏幕的進行操作，然后你錄屏。嘿嘿，曾經我就是這么做的。后來我們公司，受不了大型的視頻文件了，決定自己開發一個系統。

二、進行遠程可用性測試的最佳時間是什么時候?

是在設計過程中的任何時候。只要第一步任務的編寫完成了，那么遠程測試比現場測試進行起來更快更容易，因為可以無限的復用。

對于，某些公司缺少啟動資金，又想做的專業，那你就需要試試我的建議了?？梢源_保您的迭代始終得到數據的支持?；蛘卟桓视谠谧霎媹D仔的小伙伴，可以試著推動一下。

1. 你只需要做到編寫任務，確保任務流程非常清晰后。
2. 召集你的調研對象
3. 發送鏈接（怎么讓用戶點擊產生時間不用我說了吧）
4. 完成錄屏
5. 分析記錄的數據
6. 以及謝場

三、創建一個有效的遠程可用性測試的5個技巧

要真正看到遠程可用性測試的好處，您必須以一種能夠獲得可操作結果的方式來設置您的測試。遠程測試并不意味著更少的準備或計劃。相反，它要求以最好的方式設置測試，以獲得有效的結果，從而幫助您學習并根據收集到的數據采取行動。

1. 選擇正確的測試類型

遠程可用性測試有兩種類型:中度測試和非中度測試。

除了主持人和用戶不在一個房間之外，主持測試的工作原理與傳統的現場可用性測試基本相同。主持人需要用到騰訊會議這樣的軟件去觀察視頻通話中的用戶。

這樣做的好處是：仍然可以向用戶詢問盡可能多的后續問題，此外，用戶也不需要長途跋涉到公司參與。（像我們公司做B端產品的，運營分布上海、重慶、合肥。你說香不香。）

缺點是：它仍然需要參與者在一定程度上的投入——他們必須在特定的時間使用特定的設置來完成測試，而額外的交流使得整個測試過程更加耗時。所以就看你在開局時能不能編寫好劇本了。

要點：

對于更傳統的可用性測試過程，可以使用溫和的遠程測試；對于資金不足的、想專業性的、定量的、節省時間的方法，可以采納遠程可用性測試。

2. 縮小你的范圍

測試的范圍可以決定它成功的機會，也可以決定它失敗的機會。很顯然，我們大家都需要在某個時候對產品的每一處的功能都要進行測試。但是對于遠程測試，最好采用測試特定的流程，而不是把所有東西都放在一個大型測試中。

這有幾個原因：

首先，把你的測試集中在幾個假設上，不管怎樣都會使你的結果更加清晰。一次測試的設計越多，測試的時間就越長，結果也就越模糊。耐心嘛，總歸是有限的。

我們應該給參與者更少的選擇，這樣可以精確地確定設計決策并更嚴格地測試它們。

第二，測試越短，用戶越有可能完成它。還是那句話，注意力也是有限的。

因為我們無法在現場指導他們的方向（遠程溝通的弊端）。如果他們不能堅持到最后，你將會得到扭曲的結果。

我的建議：是將任務分成七到八個小任務的遠程可用性測試。

• 好的方面是：可以更頻繁地運行小型測試。
• 弊端就是：你需要做的復雜一點了。

中度測試：可能稍微復雜一點，因為你可以就參與者發現的問題進行完整的對話，并對他們是如何陷入困境的來做筆記。由于這些測試需要更多的時間來安排，你可能需要更深入地挖掘以最大限度地利用每一個測試。（在遠程可用性測試方面，我不大推薦這么做。）

要點：

為了獲得更清晰的數據模式、也為了確保人們完成。遠程測試不應該超過七到八個子任務。非中度遠程測試可能沒有那么集中，但同樣的原則也適用。

3. 盡快開始尋找參與者

為什么說到盡快呢？因為最根本的就是防止自己出錯！及時止損！

請記住，遠程可用性測試的主要好處之一是能夠使用大樣本進行測試。所以你能找到的用戶越多越好。（建議：尋找具有特定背景或職位的用戶）因為遠程測試是屬于定量的。（現場可用性測試的話會更加偏向于定性）別再搞混了，在搞混直接打死！

如何找：

1. C端，很常見的就是從運營手里找用戶，或者從反饋問題的頁面找到聯系人。C端找人太簡單了。我就很喜歡去反饋。
2. B端，這個就要分業務場景了，是包裝后準備售賣還是以代運營的方式。自己公司就好說，代運營得從業務部門溝通開始安排時間。
3. 搭建訪談記錄池

要點：

準備充分！及時止損！尋找特定背景/職位用戶！

4. 創建任務

當您為遠程可用性測試創建任務時，清晰是非常重要的。寫得好的和結構化的可用性任務會給你帶來更準確的結果。

要點：

• 確保目標的一致性：你想到的產品使用目標和用戶在使用你的產品時所想到的目標是一樣的。
• 提供產品背景：提前告訴參與者這個測試——它是針對什么項目的，你想要的數據類型以及設計，而不是他們自己。這會幫助他們理解你要求他們做的事情。
• 從簡單的開始：通過簡單的開始任務給人們一個機會來適應測試過程和產品。
• 使用簡潔的語言：避免使用內部術語或技術術語，因為它們可能會使人困惑。找個文化水平好一點的大師，讓他們教教你。哈哈哈，我經常被吐槽。
• 專注于一件事：想讓用戶在完成一件事之前一定要專注現在的事情。這將防止他們不知所措，并幫助您精確定位數據中的設計缺陷。
• 遵循流程：請按照產品中的常見、常規的操作流程去進行測試，這樣測試數據就更加真實。
• 不要透露答案：給人們情景，而不是方向。

“你找到這個列表，點擊這個編輯，然后填寫數據，最后點擊完成”兄弟們千萬不要這么做?。。?！這個過程太精確了——可用性測試的目標是看看人們是否可以在不提醒的情況下完成你的產品的實際任務。

要點：

如何編寫和組織任務將在很大程度上決定遠程可用性測試的成功與否。根據用戶的目標使用簡單的語言，避免讓任務太復雜或太明顯。

5. 問一些有效的問題來獲得更豐富的見解

提問是在遠程可用性測試中獲得更多反饋的一種方式。

在每項任務結束后跟蹤參與者，了解他們對具體設計元素的看法，或在測試結束時提出一般性問題，以獲得定性反饋。因為你需要為遠程測試提前寫好問題，所以它們需要是完美的。這里有一些建議:

把開放式的問題留到最后，詢問某人的整體經歷可以讓你得到詳細、定性的回答。

下面是一些我會經常問到的可用性測試問題的例子:

1. 你完成這項任務后的感覺如何?
2. 你覺得這個設計總體上怎么樣?
3. 您如何看待信息和特征的布局?

最后在拼死壓榨一下，填寫一下系統可用性度量表(SUS)的問題。這是一個經過測試的可用性調查，經常被用來衡量產品的可用性。SUS甚至會在最后給你的產品一個可用性評分。

計算評分如下：計算SUS得分的第一步是確定每道題的轉化分值，范圍在0-4。對于正面題（奇數題），轉化分值是量表原始分減去1（X-1），對于反面題（偶數題），轉化分值是5減去原始分（5-X）。所有題項的轉化分值相加后乘以2.5得到SUS量表的總分。所以SUS分值范圍在0-100，以2.5分為增量。

你也可以問一些人口統計問題來根據年齡、職業、教育等對用戶進行細分。這對于發現不同人群的可用性趨勢很有用。隱私就別問了啊。

要點：

措辭精準、請反復核對。

四、結合Think aloud

完成可用性測試（這一點是根據一位不知名的網友提供的。雖然他單詞拼錯了，哈哈哈可我還是依然給他置頂了評論)。

Think aloud釋義：

Think aloud 是可用性測試中常用的一種方法，它是由IBM公司Clayton Lewis 在1982年在 《以任務為中心的界面設計》書中被闡述，同時引進到了可用性領域，1993年由前蘋果研究院VP的Jakob Neilson在可用性工程這本書中再次推出。

使用 Think aloud方法，需要提供給被測用戶待測的產品或界面原型，要求被測用戶根據指定任務操作產品或界面，與此同時，即時地說出使用產品界面時的想法、感受和意見。

Think aloud適合在產品設計的任何階段使用，并且適用于各種形式的產品原型，對于用戶路徑，界面信息構架，誤操評估等有快速有效的校驗作用。

我在以往做可用性測試的時候，往往會忽視了參與者的即時感受。除非他自言自語，我找不到這個功能在哪了，那會兒我才反應到他為什么出現認知錯誤了?，F在經過他的留言，我才反思到是我過度的專注于實操和他的表情了。希望小伙伴們要注意哦~

作者：交互思維鋪子；公眾號：交互思維鋪子

本文由 @交互思維鋪子 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。