可用性測試是一種測試方法，用于評估產品、系統或服務在用戶使用過程中的易用性、用戶體驗和用戶滿意度。如何建立簡易的可用性測試呢？本文作者分享了他們團隊的做法，一起來看一下吧。

可用性測試是一種測試方法，用于評估產品、系統或服務在用戶使用過程中的易用性、用戶體驗和用戶滿意度。但是常規的可用性測試費用以及需要的條件比較苛刻，那如何低成本搭建可用性測試就成了一個比較難的問題。接下來分享一下我們團隊如何建立簡易可用性測試的。

一、幾點暴論

1. 一定要做測試

實際工作中即使是有同理心基礎的設計師，也因為不是實際使用用戶不知道使用過程中到底出現了什么問題。根本原因就是不是每個人都像你一樣，和你熟悉度一樣，很多事情是項目成員覺得想當然的事情，但是對于用戶而言并不是那么的“理所應當”。

2. 做不不做好一萬倍

做測試一定有效果的，哪怕是一個錯誤的用戶做一次做比較糟糕的的測試也能發現現有產品的問題。每一場可用性測試都會對于產品的的優化以及項目組成員對于產品的認知逐步加深一步。做多次可用性測試之后，項目成員能夠產生更多有價值的想法和看法。

3. 越早測試越好

這里有個常識性的誤區：就是當把系統設計的很復雜之后，做測試的價值會有更大的價值。這個常識性的誤區考慮的并不全面，再實際的項目運行之中時候，一旦產品或者是優化功能上線，修改時候就不是那么的容易。而且在用戶養成固定的操作習慣之后是很難進行改變，如果強行并且頻繁改變的話很有可能會引起用戶的反感。

這里的反感涉及往小了說是表單或則是字段的位置，大到了一個功能模塊都會產生巨大的影響，所以越早測試這種影響越能早發現/影響越小。

二、為什么要做簡易可用性測試？

1. 招募形式

常規可用性測試是需要花時間和精力來進行精準用戶目標。而簡易可用性測試則不需要精準的使用用戶，就是隨便找一些人進行測試，如果經常進行測試可能比真實用戶更有效果。

2. 主要目標不同

常規的可用性測試的目的是是需要盡可能的找到全部的問題，然后進行分類和需求的優先級排序。但是簡易性可用性測試是為了找到最嚴重的問題，并且在下次測試前解決問題。

3. 現金成本不同

之前通過第三方請過1個農業生產方面的專家（6千/小時），如果沒有到1個小時就按照比例進行計算（通常是在35多分鐘到45分鐘），一次最起碼要付出3千多到4千多。而簡易可用性測試只需要幾百元或者一些紀念品就可以給測試的用戶。

三、測試的時間選擇

常規的選擇時間是安排在每個月第一個周一的上午。

原因

1. 保持簡單些：越簡單團隊才越能堅持下去，越復雜越忙的時候很有可能就沒辦法做安排。
2. 固定 SOP就不用提前敲定時間：確定固定時間就可以按照工作流程進行安排，就減少團隊討論的時間。
3. 8 個人發現的的問題足夠一個月了：8個人已經發現85%以上的問題了，而且足夠忙一個月了。

四、可用性測試流程

1. 前期準備

1）用戶選擇

①怎么篩選標準

理想情況下是邀請精準用戶。

舉個例子：男性，倉管，34-45歲，8-10年的系統使用經驗，之前使用過這類的系統。

理想篩選標準一般是包含了：

1. 性別
2. 年齡
3. 競品使用經驗
4. 使用產品時間
5. 有沒有特殊的操作習慣
6. 日常的操作習慣

上面講的是理想情況下，但是在實際工作中因為要花的時間和精力十分的多，而且也很難找到如此精準的使用用戶，那還有一種方式叫做：條件放寬。

換句話說就是就是去尋找到與目標用戶類似的用戶，這里其實會出現一個比較大的誤區：非目標用戶無法尋找到產品中的問題？但是這里你要進行思考一下，我們的用戶出現了這個問題，是因為參與人員專業度不夠導致的這個問題嗎？

招募不是目標用戶有2點好處：

1. 如果只是針對某個專業的領域進行設計的話，就是默認這個領域的所有從業者都明白這些術語。但是這是屬于理想狀態下的猜測，但是在實際場景中不是所有這個領域的行擇業從業者都明白所有的術語，拉高新人的學習成本未必是一件好事。
2. 即使參與人員是一名專家，他也是跟大部分用戶類似的事勉強應付任務，只不過是比普通的用戶高一點點的層次。

②什么方式找到

找到用戶的的方式有很多，主要是分為對內和對外：

1. 對內的方式：成本和精力比較多的時候可以通過客戶成功找到精準的使用用戶。如果是條件放寬的條件下可以通過系統發放問卷還有微信客戶群里面尋找到合適的使用用戶。
2. 對外的方式：可以在社交平臺上發布招募需求，自主招募用戶。也可以通過第三方軟件發布招募問卷進行招募。

請用戶進行測試，別忘了準備100-200準備給測試用戶，或者是準備一些紀念品，來表示尊重。

2）環境準備

通常是需要1個安靜不被打擾的辦公室或者是會議室，同時還需要共享軟件，一般使用的是騰訊會議或者是飛書會議進行屏幕共享。另外一間辦公室里由測試組員進行觀察。復盤時候需要視頻來復盤，是一個很好的依據。

3）測試人員

通常分為2種：

1. 主持人：主持人一般是引導用戶完成任務的職責，往往也有鼓勵用戶努力去嘗試和發聲。
2. 記錄者：常常是進行操作選記錄以及防止問題遺漏進行的補充，還兼顧這觀察用戶的表情的職責。

4）觀察人員選擇

人越多越好?。?！

在做可用性測試的時候，讓參與到的團隊成員能有一個沖擊感。他們都會改變對于用戶行為的認知，擺脫以自我職業為中心的認知，這個時候會意識到我們不是“用戶”。

我們作為設計師應該邀請所有跟項目有關的成員進入到測試環節，這里除了常規的成員：技術和產品外以及業務方，還需要邀請到決策層以及上層的主觀進入到測試環節中（把決策層和主管拉進來也是為了后面能拉到更多的資源）。

小技巧：如果預算足夠的，可以買一些零食，個人推薦巧克力和薯片還是不錯的。

5）如何選擇測試任務

測試任務取決于現有產品需要需要測試什么流程或者是功能，需要提前拆分功能的流程，就像是就設計劇本殺一樣一關一關。將流程進行拆分，然后以卡片的方式在白板上進行展示，并給與所有成員進行講解。

以一個常規的新建用戶為例：

1. 錄入信息
2. 核對資料
3. 驗證密碼

6）提前準備時間

一般從邀請用戶到中期的測試流程，一般都要提前1周2周完成。大綱整理差不多1天2天時間就可以完成了。

2. 中期執行

1）歡迎（大概4分鐘）

處于開始測試環節并且講述測試的規則，讓測試用戶有個心理準備：

①臺詞部分

需要提前將準備的臺詞讀出來，需要跟測試用戶進行確認。

②安慰部分

這部分是很容易被忽略的部分，這里如果做不好的好的話容易得罪測試用戶。這里需要聲明3個點：

1. 主要是做產品的測試，而不是測試用戶個人的能力。
2. 要鼓勵用戶發聲
3. 測試結束之后，一定要還有問測試用戶還有什么問題，盡力解答這些問題

③情況說明

如果有錄像或者是錄音的存留必須要要跟測試用說明，不強求用戶的測試，即使用戶退出也應該給與一些補償。

并跟用戶簽署授權/豁免協議。

2）提問（2分鐘左右）

主要是詢問幾個與測試贊譽這相關的問題，主要是讓測試用戶放松一些還有了解一下時候有之類的產品的經驗，以便于進入下一個階段。

提問部分涉及到了3個注意點：

1. 讓測試者有主角感，而不是一個單純做任務的人。
2. 不要注重問題回答的準確度，主要是用戶習慣。
3. 2分鐘內需要迅速拉回來。

3）觀光（3分鐘左右）

提前打產品頁面，讓用戶瀏覽即將要測試的頁面，請參與者講講具體看到了什么，以及哪里看不懂的地方。視覺問題在這一步就可以檢查出一部分的問題。

然后把操作設備的主動權交給測試者。

4）任務測試（大約35分鐘）

這是本次測試的核心環節，主要是讓測試用戶操作指定的任務，并且通過用戶一些的操作以及用戶的發聲找到產品中的問題。

在整個任務測試過程中，全程讓測試者自己走完全程，作為主持人不要引導/影響到用戶的判斷與決策，在發出提問的時候避免掉會引導用戶操作的的問題。除非測試這個時候已經停止操作以及處于絕望的時候，不要給與幫助與接下來步驟的引導。如果發現測流程多次出現測試的求助，則記錄下來并且詢問具體的原因，還要跟測試者溝通好如果主持人不在的場景下怎么處理？

測試流程中有2個要關注的的點：

1. 發生原則：盡可能的鼓勵用戶的去說出他/她現在所處的流程以及現在碰到的難點還有疑惑的點，尤其是是測試者開始停止操作且不再說話的時候，可以試探的問一下：你在想什么？遇到了什么問題？
2. 時效性：一定要去學會控制時間，測試全流程要控制到45分鐘，一旦拖到了一個小時測試用戶和主持人就會陷入疲態。

5）探查（4分鐘左右）

任務測試完了之后，有些場景下主持人或者是記錄者需要補充詢問道一些問題，還可以向觀察室里面的成員搜集他們想問的問題詢問到測試者。

6）結束（3分鐘左右）

最后感謝測試者加入到測試當中，給予測試者之前承認的報酬（金錢或者是其他報酬），并恭敬地將測試者送出門。

交付物一般情況下是：

1. 視頻
2. sus測試表格

7）常見的遇到什么問題

常見的可以分成3種：

1. 不理解產品：由于不熟精準的用戶目標，又有大的概率沒用這一類的產品所以多少會迷茫。
2. 功能找不到：如果單頁多次發現這種功能找不到的情況下，要考慮下是不是在設計的時候要突出視覺層次
3. 專業詞匯不理解：專業詞匯過多的頁面針對非這個行業的測誰這來講理解成本很高，所以會早造成操作流程的卡頓與停止，這里產生的原因極有可能是因為設計的時候沒有考慮到新人的認知成本以及操作成本。

3. 后期復盤

1）分類排序與問題評級

首先按照是職責區分：

1. 功能增減-產品
2. bug-開發
3. 體驗問題-UX設計師

然后講每個問題進行分級：最嚴重的是P0，P3是最輕的，并進行任務的排期。

2）忽略“皮劃艇”問題

先解釋下什么是“皮劃艇”，就是用戶在短時間發生了錯誤之后，在沒有任何幫助提示下就能修改過來的問題。就像皮劃艇在水流中一樣，有的時候水流沖擊下會向左或者是向右偏離一下，但是能夠快速調整回來，一般遇到這種問題直接忽略就好難免會發生的事情。

五、其他測試方法

1）遠程測試

這個使我們團隊在疫情期間使用的一種可用性調研方式，測試用戶不用來辦公室進行測試，只要通過視屏共享就可以進行流程。這模式主要針對工作繁忙的用戶，但是在疫情期間反而起了奇效。

2）無主持人的遠程測試

就是在規定時間內讓用戶使用產品/任務流程過程中進行錄制視頻，從而讓操作完成之后團隊成員通過視頻進行分析即可。