可用性測試，能夠讓產品經理借助用戶，更加客觀理性地理解產品功能以及交互，並結合測試結果予以改進。
1. 可用性測試介紹
1.1 可用性測試（Usablitity Testing）
不知道你作為產品經理、交互設計或視覺設計時，會不會困惑於功能操作是否合理，交互是否流暢，視覺提示是否能夠引起足夠註意等問題。由於設計人員對自己的產品和功能的交互設計過於瞭解，往往無法客觀判斷其可用性，這時候就急需對用戶進行可用性測試。
可用性測試是指讓一群具有代表性的用戶按照指令對產品進行典型操作，同時觀察員和相關人員在一旁觀察、聆聽、記錄。
該產品可能是一個網站，軟件，或者其他任何產品。可用性測試可以是早期的紙上原型測試，也可以是後期成品的測試。隨著現在的工具越來越敏捷，即使是低保真的交互原型圖也可以通過類似於墨刀或者Figma等工具，可以讓用戶直接上手進行簡單交互操作。
1.2 可用性測試和深度訪談之間的差別
可用性測試偏重於觀察用戶使用產品的行為過程，而深度訪談一般是洞察用戶動機、態度、訴求為導向，通常深度訪談需要更加關註不同城市、性別、年齡段、收入等方面的用戶，瞭解不同類型用戶之間對產品態度和訴求之間的差異。
一般的可用性測試在以上方面的影響是比較小的，一般來說，對同個城市5-6人進行可用性測試，就基本能夠暴露產品的一些共性的問題，滿足一個快速洞察其可用性的測試需求。
1.3 對產品的意義
可用性測試可以發現用戶和產品之間存在的交互問題，瞭解產品的可用性水平。在可用性測試中加入A/B Test測試，幫助判斷用戶方案的偏好。在完成可用性測試之後，整理研究數據，通過報告輸出的方式，進而對後續產品優化具有指導性意義。
2. 準備工作
2.1 評估模型
可用性測試主要圍繞有效性、效率性、滿意度進行展開：
- 有效性（Effectiveness）：任務完成情況；
- 效率性（Efficiency）：任務完成時間和完成路徑；
- 滿意度（Satisfaction）：用戶自我報告數據。
針對以上三點，將效率性的完成時間和路徑進行拆分，可以得到以下四個評估模型以及標準。
2.2 提綱準備
可用性測試的提供是依據預先制定的測試目的，分解目的，列出任務列表，將任務場景化，來編寫提綱。暫且用以微信理財通舉例，測試用戶購買理財產品的可用性。
購買的任務可以分解為：
- 進入理財通
- 隨意瀏覽並對比理財產品的收益
- 選擇一個理財產品並買入該產品
- 管理和查看收益
- 賣出該產品
在這個基礎上對於任務進行場景化設計：
場景：您剛剛發了工資，瞭解到微信理財通可以購買理財產品，準備以此來購買理財產品。
任務一：請在微信中找到購買理財通，併進入；
場景：為了瞭解理財產品的性質和收益的不同，您想要對比一下再進行購買。
任務二：在理財通中隨意瀏覽對比理財產品，並選擇一個想要購買的產品。
…
以上只是我提供的一個思路，意在說明需要拆分單個的操作步驟，再適當整合併進行場景化設計對用戶進行測試。
提綱的編寫應該始終圍繞用戶使用目標，難點在於：
- 順序的設置，應符合典型用戶的操作流程，操作舒適自然，符合常態；
- 任務描述方式，避免直接指出指導操作，不能過於詳細，但也不能過於寬泛，而產生歧義和茫然，需要掌握描述的平衡點；
- 控制任務數量，測試時間過長用戶會疲倦，任務的保留和捨棄思量也相當重要。
2.3 資源&人員準備
資源準備包括測試環境和工具，包括辦公室、觀察間、保密協議、禮金、網絡、測試設備（手機、電腦等）、賬號預登、麥克風、任務卡、錄屏軟件、屏幕共享軟件、攝像機、眼動儀等。
比起深度訪談，可用性測試需要用到的儀器較多，一定要提前抵達辦公室，進行調試。在上一個用戶測試完後，一定要恢復初始化狀態，清除數據等，便於下一個用戶測試使用。
人員準備，除了記錄員和相關人員的就位，主測人員需要熟悉產品，能夠全面體驗所測試的功能界面，知道用戶說的是什麼，以及當用戶進行提問時，能夠解答用戶問題。
2.4 測試預演
測試預演非常重要，能夠幫助瞭解提綱任務設置是否合理流暢，驗證時間是否在預想內，主測人員會不會有什麼卡殼或者對產品也不熟悉的地方等等，測試預演完成之後，一般都會再進行提綱的修改。修改完成後可以再進行預演，能夠在時間和流暢度上有把握之後再進行正式測試。
3. 用戶邀約
3.1 用戶選擇
甄別用戶需要問卷調查建立有效的甄別條件，立足自身產品，選取有效的維度標準，可能需要知道用戶的年齡、性別、使用頻率、個性特征等甄別是否為典型用戶。
如果不是針對性強或者專業性強的產品，用戶挑選也不必過於嚴苛，可用性的關鍵還是普遍兼容，任何人都可以上手使用。
但一般來說，對產品的使用&熟悉的程度對可用性測試的結果影響較大，用戶甄別時，需要選取一定比例從來沒有使用過該產品的用戶。
3.2 用戶邀約和double-cheek
通過電話的方式與測試用戶進行邀約，電話中一定要告知一些關鍵信息，和用戶確認時間和地點。不管是一般的用戶訪談還是可用性測試，用戶爽約的情況時有發生，所以在開始前一天的晚上也要再提醒測試用戶，確認是否到場。
本文由 @舒季 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議