全栈工程师?
嗯.....目前并不是!

實踐復盤丨如何完整地進行一次可用性測試

可用性測試是通過觀察有代表性的用戶,完成產品的典型任務,發現產品的可用性問題,達到改善產品的目的。本文將按照測試前準備、測試執行、結果整理三大模塊進行展開,總結其中需要注意的地方。

一、測試準備

這部分包括資料收集、相關材料準備、用戶招募等

1. 資料收集

可用性測試本質上也是一種研究類型的工作,作為研究類的工作,那麼做一些前期的資料收集也是有必要的,這有助於幫助我們界定需要研究的主要問題,好比我們在寫論文的過程中,需要先閱讀相關的文獻。

在資料的收集方式上,主要有以下幾種方式:

(1)定性訪談

前期可以找一些用戶,尤其是產品使用經驗比較久的用戶進行訪談,這個訪談可以盡量發散,不局限於某一功能和某一方面,這樣能夠比較全面的了解產品的相關功能信息。

(2)焦點小組

組織一次小範圍的討論,了解大家對於產品的使用情況和反饋。

(3)研究競品

如果產品有相應的競品,也可以進行競品分析,對比彼此在功能上的差異性。

(4)其他包括參考相關的研究報告、相關的可用性測試案例等

在本次研究中,我們找了5名有產品使用經驗(都在三年以上)的用戶進行了訪談,並且也對競品進行了研究,然後我們將得到的結果進行初步的整理歸納。前期的資料收集可以根據項目的整體進度安排時間,建議訪談一定要做,其他可選。

2. 材料準備

需要準備的材料主要包括:可用性測試腳本、任務條、相關評估量表、禮物簽收表、測試的產品及版本號、相關記錄(錄音、錄像、計時器等)工具

(1)可用性測試腳本

測試腳本是指導測試進行的工具,內容包括:基本信息、測試指導語、場景任務、任務評分題、事後訪談問題。

1)基本信息

一般包括被試的姓名、性別、產品使用經驗、測試開始/結束時間、主持人、記錄員等。

2)測試指導語

向被試介紹測試的目的,需要注意的事項等,測試前也可以做一個簡短的訪談,了解用戶對產品的使用情況,幫助用戶將注意力轉移到產品上,為測試做準備。

3)場景任務

根據測試的目的,選取需要測試的功能,在此基礎上,將任務場景化,這樣更符合用戶平時的使用習慣,也避免生硬的表達,這裡需要注意兩點:

a. 在任務場景化的過程中,避免提及與測試功能有關的詞彙,以免對用戶造成暗示。

  • 錯誤示例:請搜索聯繫人XXX,並給他發送消息
  • 正確示例:在系統中找到聯繫人XXX,並告知他下午要開會

b. 任務應該涉及詳細的操作,而不是籠統的描述

  • 錯誤示例:請發送一次會議邀請
  • 正確示例:請發送一次會議邀請,時間為XXXX,參會人員為XXXX,會議地點為XXXX,會議主題是XXXX

4)任務評分題

在每一次任務完成後,可以讓用戶對任務進行評分,注意評分要有相同的維度,否則無法進行統計。比如可以從產品功能的滿意度、操作的便捷性滿意度進行評分,評分可以採取5分制或者7分制。

最後統計的時候可以分別計算產品的功能滿意度和操作滿意度總平均分,將單一任務的平均分與總平均分進行參照對比,了解用戶對功能的評價情況。

5)事後訪談

在完成每一次的操作任務后,可以對用戶進行訪談,訪談的邏輯可以參考“基於過去和現狀,你的期望是什麼”,因此提問的方式可以參考:

  • “在平時使用的過程中,您有遇到什麼問題嗎?您是怎麼處理的?”
  • “目前的功能能否滿足您的使用需要,您認為還需要哪些功能?”

(2)任務條

1)將任務條裁剪成相同大小,消除挑選時外觀的誤差影響

測試的任務條盡量做成相同大小,進行裁剪,這樣在挑選單條任務給用戶進行操作時,不容易受外觀不同這一誤差的影響,保證能夠隨機挑選。鑒於大部分用研都不是專業的設計師,任務卡片可以直接在Word中插入一行表格的形式,空行保證相同,這樣裁剪的時候大小就一致了。

2)任務隨機進行,消除順序效應的影響

每次測試的時候將順序進行打亂,消除順序效應的影響,避免前面的操作對後面產生影響。

(3)其他的材料包括評估量表(一般可以採用SUS量表進行評分)、禮物簽收表等

3. 用戶招募

用戶招募的關鍵之處在於所招募的用戶要具有代表性,數量一般在10名左右即可。可以根據產品後台的使用數據,了解用戶的群體特徵是怎樣的,比如設備類型、性別比例、年齡分佈等,這些即構成招募的條件,然後我們可以對招募的用戶信息進行整理。

二、測試執行

這一部分是整個測試的關鍵環節,操作執行的好壞直接影響到整個可用性測試的結果。在操作執行中,最重要的就是觀察和記錄用戶的行為。這裡需要注意幾點:

(1)在用戶操作的時候盡量不要打擾用戶,觀察和記錄疑問的地方,事後再進行訪談

比如:用戶可能操作的時候出現遲疑,做思考狀,事後可詢問原因是什麼。

(2)用戶所說的固然重要,但用戶所做的更加重要

不管用戶如何說,堅持讓他完整操作一遍任務

在測試中,我們發現,有用戶認為這一任務很簡單,因此只是大致向我們示意了一下,實際並沒有完整的執行這個任務,當我們要求他完整執行整個任務流程時,依然發現了一些問題,因此一定要讓用戶執行任務操作,而不是簡單示意,或者說“這個任務很簡單,我知道怎麼做,就不用演示了”等之類的話語。

當提問用戶關於某一功能模塊的問題時,可讓用戶邊看邊回答

對於很多的產品功能模塊,或許我們平時已經使用較為成熟,已經習以為常,但如果是在不看着產品的情況下,我們並一定能夠進行完整回憶。比如我們日常使用的微信,其聊天對話框裡面的功能,我相信很少有人能夠在不看着的情況下完整說出來。因此,當提問用戶具體某一模塊的功能相關問題時,可以提示用戶邊看邊進行回答。

鼓勵用戶進行操作時進行“發聲思維”

所謂“發聲思維”,就是讓用戶邊操作時,邊口述自己的想法。

不僅要記錄顯性的回答話語,也要記錄隱性的行為和表情等

用戶的回答揭示了其個人的感受和體驗,這是我們需要關注和記錄的,但用戶在操作中的行為和表現出來的情緒,也是值得關注的,更何況在某些情況下人的言語與行為存在不一致的情況。

因此在記錄時,既要記錄用戶的言語回答,也可以括號備註用戶的行為和表情中隱性的信息,這樣事後看記錄結果時,也能夠聯想起當時的場景,當然這對用研人員的觀察力提出了一定的要求。

三、結果整理

1. 原始結果的整理記錄

這一部分的整理記錄,應儘可能詳細,方便後續核對和查閱,形式可以整理如下:

2. 結果分析整理

結果分析整理可以從定量和定性結果兩方面進行,定量的結果可以分析任務的完成情況、任務的滿意度等,並藉助可視化的圖表進行展現,比如:

(1)統計任務的滿意度評分情況,並與總均值進行比較,對於評分比較低的功能則需要引起注意

(2)統計任務的完成情況

任務完成一般可以分為一次完成、多次嘗試完成、經提示完成、任務失敗四種情況,不同的完成情況用不同的色塊表示,然後統計完成率情況,整理結果可以參考如下:

(3)定性結果的整理

根據用戶回答的情況,進行概括總結,歸納問題點集中表現在哪些方面,可以整理為:

功能三,操作交互體驗不佳:

①長按提示功能沒有整合

②滑動跳轉不符合正常操作習慣

……

(4)撰寫測試研究報告

將得到的結果進行凝練總結,形式上按照“總-分-總”的格式進行,內容上按照“提出問題-給予建議-後續研究”的線索進行撰寫。報告要具有一定的結構性和提煉總結,做到條理清晰,有總結和挖掘,同時能夠提供的意見和建議以及後續的研究進展和方向等前瞻性的內容。

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《實踐復盤丨如何完整地進行一次可用性測試》
文章链接:https://www.pmbear.com/archives/9401
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们