手把手教你如何進行可用性測試匯報-產出匯報篇

3 評論 4853 瀏覽 20 收藏 14 分鐘

編輯導讀:可用性測試(Usability Testing)作為用戶體驗研究中常用的一種方法,其核心在于對典型用戶執行典型任務的觀察記錄,以發現產品設計中存在的可用性方面的問題。本文作者圍繞可用性測試進行了分析,希望對你有幫助。

可用性最早來源于人因工程,起源于二戰時期,設計人員研究新式武器時,研究如何使用,人的能力限度和特性。國際標準ISO 9241-11對可用性的定義是“特定的用戶在特定的使用情景下,有效、有效率、滿意的使用產品達到特定的目標”。

Web易用大師尼爾森在可用性工程中將其定義為用戶能否很好地使用系統的功能;分為五個因素:可學習性(learnability)、效率(efficiency)、可記憶性(memorability)、出錯(errors、滿意度(satisfaction)。我們軟件產品可用性評估屬于界面視窗的評估,因此通常采用的是尼爾森的理論。

一、典型用戶與典型任務

可用性測試(Usability Testing)作為用戶體驗研究中常用的一種方法,其核心在于對典型用戶執行典型任務的觀察記錄,以發現產品設計中存在的可用性方面的問題。這里的典型用戶,最好就是招募真正使用產品的用戶;其次是產品的潛在用戶或者意向用戶,他們現在可能沒使用我們的產品,但是未來有大概率可能使用;再不濟就是我們內部自己人以認知預演的方式進行評估。但越是接近真實用戶,效果是越好的。

那這里的典型任務,就是產品關鍵場景下的任務,是指產品的核心功能、用戶操作頻度最高的功能。作為觀察記錄的研究人員,通常是由UED專家、產品經理構成,像我們產品的用戶很多都是技術人員,在可用性測試的擴展性訪談中,難免會溝通一些技術性問題,所以最好再有一個開發人員的參與。

二、可用性測試匯報內容

可用性測試產出匯報的具體內容包括調研介紹、結果概述、過程分析、后續計劃及附件五個部分。

1. 調研介紹

第一部分,首先對本次可用性測試的背景與目標、人員與流程以及測試任務做介紹。

背景:對當前測試產品所處的階段以及本次可用性測試需求產生的背景進行描述,說明是由于客戶需求呢還是產品部需求還是UED驗證或優化需求等。

目標:基于背景前提下,描述本次可用性測試期望達成的目標。

測試人員:參與可用性測試研究的產品方成員,一般由UED、PM、開發等構成。

測試流程:對本次測試的流程進行描述,一般采用可用性測試標準化流程,即資源準備-任務設計-用戶招募-預測試-正式測試-測試報告。

招募用戶:介紹招募到的用戶所屬機構/部門、角色及人數。

測試任務:展示本次可用性測試的任務單,任務總數與涉及功能總數。任務單要素包含角色、任務大類、操作目標、場景任務描述、任務涉及的功能。其中場景任務描述最為關鍵,需要交代任務的前置場景,讓受眾能夠產生畫面感。

2. 結果概述

第二部分是整個可用性測試的最終結果,包括體驗度量結果、客戶重點評價以及通過用戶反饋和專家分析,梳理出來的可用性問題概況。

體驗度量結果:整體度量指標包括SUS可用性評分與對應的評級、百分等級;用戶整體滿意度、問題點統計以及效率相關的任務完成率、錯誤次數、提示次數、完成時間等指標。我們在可用性測試結束后,會發放問卷給參與用戶,包含SUS評分與整體滿意度。通過SUS評分換算可得到SUS可用性評分、評級及百分等級。如果相同的任務可用性測試不是首次,則可與之前的測試度量結果做比較,以體現產品優化后的效果提升。若沒有,則僅展示本次結果。需要說明數據來源與幾家客戶、幾類角色、幾位用戶、幾份有效問卷。

SUS可用性評分:通過將用戶打分轉換而來,反應總體可用性。

評級:一共為A、B、C、D四個評級,低于D則表示產品可用性極為一般,甚至糟糕。

百分等級:是指測量的產品或系統相對于總數據庫【Jeff Sauro(2011)通過446個研究,對于我們目前的產品有一定缺陷,但在沒有更權威的選擇下,值得應用】里其他產品或系統的可用性程度。比如SUS得分是73分,其百分等級大約為67,意味著比大約67%的產品可用性更好。

SUS可用性評分、評級、百分等級之間的關系如下圖(SUS分數等級(Bangor et al.))所示:

整體滿意度:接受可用性測試的用戶對產品的主觀感受,我們通過在SUS量表問卷中額外附帶的滿意度百分制打分獲取。

問題點統計與分類:來自現場客戶發生思考吐槽、擴展性訪談反饋以及測試完成后的專家回顧分析評估得出的可用性問題總數,并對這些問題進行歸類。

任務完成率:通過可用性測試過程中的觀察記錄表,記錄用戶對任務是否完成、錯誤次數、提示次數以及完成時間。而完成率則是將角色維度將所有用戶的數據加權平均計算得出。由于B端產品的復雜性,可用性測試過程中的不可控因素過多,往往無法準確獲取錯誤/提示次數、完成時間,因此,我們通過專家討論,僅將完成率作為匯報中的必須項。

客戶重點評價:包括客戶差評與好評,是最為直觀的以客戶發聲方式體現對產品的評價,相信也是報告受眾非常關注的點。此項往往在擴展性訪談中獲取,且未必能夠獲取到,因此作為匯報內容的可選項。

問題及分類:得出可用性問題匯總數量、計劃落地數量,并從中得出體驗優化建議的采納率。圖形化展示問題分布及優先級。

3. 過程分析

對可用性整個過程進行詳細的闡述。包括準備工作介紹、用戶角色建立、場景化任務具體分析及問題總表與評估結果。

準備工作:說明對招募的用戶及約定的可用性測試的時間安排;所使用的測試環及環境數據的準備;文檔的準備包括場景化任務表、SUS體驗度量與滿意度調研問卷、用戶行為記錄表;測試過程影像保存的方式說明,比如是通過手機拍攝的還是錄屏的、可用性測試執行的場所說明,比如真實客戶測試的話一般都會在客戶現場進行,如果是內部用戶的話一般都會在公司的辦公場所。

場景化分析:場景化分析是通過描述什么人在什么情況下做什么,存在什么問題,建議如何解決的方式,描述可用性可用性問題及建議。首先對場景化分析做簡單的說明,然后交代場景化分析中的用戶痛點具體來源。可用性測試中,問題通常來源于任務測試過程中的用戶發生思考、請求幫助;任務結束后的擴展性訪談;整個測試結束后的專家分析與評估。

角色建立:通過用戶角色模型的建立,讓受眾了解測試用戶的基本特征,包括姓名、崗位、崗位工齡、使用系統的目標、日常系統使用情況。并在后續具體場景中進行角色代入,以便于與受眾之間形成共鳴。有幾類角色就應展示幾個。

場景化分析:包括場景任務描述、操作角色與涉及功能、體驗度量結果、問題描述與方案建議。如果測試的任務之間在線性關系,則可以以任務流的形式進行串聯,便于受眾對整體流程的理解,如果沒有則直接以角色或任務維度展開。這里的體驗度量結果,是對單任務的記錄與分析,包括任務完成率、出錯/提示的次數、任務完成時長、問題點統計與分類。我們還需要羅列場景化測試中的問題/痛點,并一一給出建議,對于問題通過外鏈來對標到拍攝的視頻或圖片,以便于聚焦問題的真實發生場景。有幾個測試任務,就需要展示幾個場景化任務分析。

問題總表及評估結果:過程分析的最后,我們將得出一張問題總表,也就是通過場景化分析最終得出的可用性問題列表。以角色維度,說明任務大類、操作目標、涉及功能、問題描述、建議方案、問題類別、優先級,并對標視頻時段/截圖,便于問題定位追溯。這部分內容可根據量級決定放在PPT內還是以附件形式展示。

4. 后續計劃

后續計劃包括方案落地及驗收計劃、方案驗證計劃。方案落地及驗收計劃:主要介紹可用性完成后的后續問題評估結果、執行人等,也即方案落地及驗收計劃。

方案驗證計劃:是對優化后的產品再次進行可用性測試的計劃說明,或對招募用戶在優化落地后進行回訪計劃的說明。

5. 附件

在產出物的最后,我們附上相關的附件,提升本次可用性測試的信度。大家可以根據實際情況,展示測試中用到的文檔如可用性測試任務、測試現場影像、SUS體驗度量與滿意度問卷收集情況、任務測試記錄表等。

 

本文由@janinejly 原創發布于人人都是產品經理。未經許可,禁止轉載。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感謝作者分享?。?!對我個人來說很有用,先碼住后面再仔細看看

    來自廣東 回復
  2. 看懂了好像又不太明白的樣子,先收藏著,待我日后慢慢研究!

    來自安徽 回復
  3. 介紹的測試匯報內容特別實用,能讓我們的工作有好的結果。

    來自浙江 回復