充滿敏捷力的迭代型易用性測試 Rapid Usability Testing
身為 Product Designer 你一定多少聽過易用性測試 Usability Testing，今天要跟各位分享的是充滿敏捷力的測試方式 — 迭代型的易用性測試 Rapid Usability Testing。
本篇適合：對易用性測試不熟悉的設計師、喜歡敏捷力的設計師、正好要做易用性測試，覺得以往的測試方式太緩慢，希望可以在測試時有迭代 prototype 的設計師。
Rapid Usability Testing 五步驟
所謂 Rapid Usability Testing 概念是在易用性測試中，根據他們的反饋不斷的、快速的、及時的迭代你的 prototype 給新的受測者，而迭代的次數端看受測者是否已成功完成任務，和測試團隊是否接受該版本為最終版本，我自己迭代的平均值大概是 5 次左右 🤯
- 第一個版本的 prototype 製作：我認為可進測的 prototype 不是依照高低保真度區分，而是 prototype 是否足以讓受測者在測試時，不會混淆這是假的產品 prototype，不需要華麗的轉場，但產品該有的 ui/ux 請不要隨意減少，當然要做到什麼程度還是要根據你的目的調整。
- 進行 2–3 位受測者測試：在這過程中會出現與你預期不符合的行為和認知，請將這些結果清楚的記錄下來，同時把受測者提供的想法加入受測結果。
- 第二三四五…版的 prototype 製作：將上一步驟測試後的結果轉化或修正到 prototype。
- 每改一個版本，就進測 2–3 位受測者：步驟 3 到 4 這個階段會不斷的輪迴，直到你測試到一個版本是你滿意，受測者也與你有相同認知的版本後，才會進到步驟 5。
- 找出最終版本，結束。
Rapid Usability Testing 就是不斷重複上面的行為，直到你設定的任務受測者都正確地完成再停下來，當然如果很致命的問題，也請你不要猶豫地取消接下來的測試。
一次 Rapid Usability Testing 需要規劃哪些事？
1. 訂定本次的測試目標
一般來說易用性測試會有一個主要的任務，但一系列反映的 flow 對測試來說更為非常重要，我通常會把想要知道的受測者認知、行為、流程或任務…etc 都安排進目標中，列好目標後面的測試流程才不會跑掉。另外還會再觀察一些受測者基本的行為，或是其他較小的反應。
2. 受測者與數量
當然是盡量找產品主 TA 範圍內的用戶，但有時我會參幾個不是想測的平台的用戶，為的是希望了解 prototype 是否有沒注意到的門檻。
而每個 prototype 版本盡可能讓 2 位以上的受測者測試，為的是避免行為變成五五波，和確認這個問題是真的值得被修掉的。
假設礙於成本或時間等因素考量，只能用內部測試的方式來做易用性測試，那還是請與專案毫無關係的同事來測試，且接近主要 TA 的人來測試，測試流程也請照正常流程跑。ex. 行政同事、行銷…etc
3. 約訪的受測時間間距
我通常會在 2–3 位測試者之後安排一個比較長的空檔，在這空檔除了消化前 2–3 位所提供的反饋外，還要根據反饋出下一版本的 prototype，其實這蠻耗時間的，所以記得規劃時多留一些時間給測試團隊。
我自己經驗的話，至少在下一次測試我會留工作時間 4–5 小時左右比較保險，但實際上還是要看你測試的 prototype 範圍有多少，如果只是 1–2 個頁面，那 1–2 小時可能也綽綽有餘，如果是 20 個頁面，留個兩天也不為過～
4. 寫一個基本的測試流程
流程只是為了讓設計師或研究員避免在測試時手忙腳亂，所以我會盡量寫的分出區塊，一眼晃過去就可以大概知道下一步要做什麼，這樣可以讓流程更順暢。
5. 測試結果統整與結論
開始測試前我會有一張可以統整的測試板，上面可以記錄受測者基本資料、測試時的錄影錄音、測試的 prototype 版本、該版本調整了什麼、目標改變什麼、受測者的詳細任務和每個任務執行的結果…
特別提一下，每一次改動 prototype 版本，請記得紀錄本次調整了什麼、目標是否有因應調整而改動，每個受測者分別受測了哪個版本…etc
測試時會是 1 位主問，另 1 位逐字稿紀錄，每次測試結束後，我們都會用逐字稿搭配受測者螢幕錄影的行為把結果記錄到表上，並且在表上用不同顏色 high light 受測者在任務中的「認知錯誤」、「認知不正確」和「其他額外想法」。
這樣的板子，除了可以讓執行測試的人一目瞭然每位受測者的測試結果外，對沒有參加測試的團隊成員來說，也能夠一下就看懂問題點在哪裡，非常方便溝通，特別是在疫情期間 WFH 需要高溝通成本的時刻。
額外說一下，這次測試是在線上做的，做的方式是提供 InVision 連結給受測者，再請受測者透過 Google Meet 分享螢幕進行。
6. 如何是否要將反饋放進下個版本？
在做易用性測試、使用者研究或平時用戶反饋時，請記得反問自己：
- 常理判斷這是情緒反饋還是產品反饋？
- 這是不是真的問題？
- 問題源頭是什麼？
- 相同問題反饋的數量多嗎？
- 你打算如何修正反應到產品上？
- 修正時間會很長嗎？適合迭代嗎？
- 是 bug 還是是 issue？
- 這個反饋與本次目標有對齊嗎？
測試、研究、用戶反饋是為了要讓團隊降低做產品的不確定性，和理解用戶的認知，如果照單全收用戶的反饋，很容易會讓團隊執行更緩慢、目標偏離甚至讓你的產品變得四不像。
Rapid Usability Testing 迭代的好處
比起一般的易用性測試，迭代型的易用性測試對團隊來說是一個非常敏捷的作法，敏捷開發的核心精神是及早且持續的交付有價值的成果，而 rapid usability testing 就是在短時間內頻繁的交付可測試的商品或服務，藉此更快地提供價值，並驗證用戶需求與團隊的假設。
雖然這樣的測試方式會十分忙碌，且有下個測試時間的壓力，但以過去經驗來說，在這樣迭代的過程裡，快速假設和快速驗證可以加速非常多產品的決策，且在測試中不只是找到用戶的行為癥結點，更可以在癥結點中找到多個可能調整的方向與機會。
Rapid Usability Testing 迭代的心態
每一次測試的版本進測後其實挫折感蠻大的，你的假設會失敗，然後重新設定假設，然後又失敗，直到找到對的方向才會順過去，所以在做的時候，請用開放的心態面對你的設計缺陷，並持續保持樂觀，且成為一位敏銳的觀察者，觀察受測者各種細微反應，有任何疑惑都盡可能詢問受測者當下的感受，不要心急於引導用戶達成你想要的任務，或你的假設，過程的反饋才是測試的精髓所在。
而在做迭代的 prototype 時，調整的問題請找用戶最大的癥結點來調整，你的時間有限，一定要排序問題優先順序，把最需要調整的找出來，有些可以直接判斷有問題的小型行為之後再來改就可以了。
感謝讀完，希望可以幫助到想要做易用性測試的你，如果有問題或其他想法也可以留言與我們一起討論，一起成為更好的產品設計師！💚💚💚
👏 如果喜歡我們的文章歡迎幫拍拍手，你的拍手數是我們寫文章的動力，有想看我們寫哪方面的文章也歡迎底下留言，我們會努力產出好文章的 👏
