在上一篇我們聊到設計中常見的 UI/UX 易用性陷阱。

不過就算設計師和團隊再有經驗，也難以保證一開始就能做出完全符合使用者直覺的產品。因為設計不只是在畫面上的美學，更是與「真實人類行為」密不可分。

這就是 易用性測試（Usability Testing） 出現的理由：透過觀察、測試和數據，來驗證設計到底能不能真的被「用得好」。

什麼是易用性測試？

簡單來說，易用性測試就是 讓真實的使用者實際操作你的產品或原型，同時觀察他們的行為與反饋。目標不是測試使用者的能力，而是測試設計是否符合使用者的自然操作邏輯。

舉例來說：

• 如果一個人要找付款按鈕，卻花了 30 秒以上還沒找到，那問題可能不是他笨，而是你的設計不明顯。
• 如果使用者在填表單時，不斷重複點擊「下一步」卻無法成功送出，那可能是錯誤訊息不明確。

易用性測試的核心精神，就是發現「設計的陷阱」在哪裡，讓團隊能更快修正，避免產品正式上線後才被大量客訴。

為什麼要做易用性測試？

可能會有人問：「我們設計師和 PM 都看過了，還要找人測試嗎？」

我會跟你說：需要‼️理由有三點：

1. 設計團隊的盲點
   設計師和 PM 常常對產品太熟悉，導致無法從「第一次使用」的角度去看待。易用性測試讓我們看見新手用戶的真實困難。

2. 避免成本高的錯誤
   一個上線後才被發現的重大體驗問題，調整成本可能是設計階段的 10 倍。測試可以把風險往前移，並縮小修改成本。

3. 真實數據支撐決策
   不是誰的意見比較大聲，而是使用者的行為說了算。測試結果能讓團隊更有依據的去說服業主並做設計上的調整，減少被業主魔改的機會☠️。

易用性測試的基本流程

1. 設定目標與指標

在開始之前，先定義清楚要測什麼。例如：

• 受測者能否在 1 分鐘內找到產品分類？
• 填寫表單的流程是否流暢？
• 首次進入新功能時，是否理解操作方式？

此外，也可以搭配幾個常用指標，像是：

• 完成率：多少人能成功完成任務？
• 完成時間：平均花多少時間？
• 錯誤率：過程中發生幾次誤操作？
• 滿意度：受測者覺得體驗如何？

這些數據能幫助團隊更有依據的去比較不同版本的設計，而不是只靠「感覺」。

2. 規劃測試任務

給受測者一些　「貼近真實場景」的操作任務，而不是讓他們自由亂點。像是：

• 「請幫我預約下週三 14 點的英文會話課程」
  👉 這樣的任務能觀察受測者到底是用課程類別來搜尋特定課程，或是關鍵字來搜尋 … 等等的使用行為跟你想像的是否一樣，以及是否有優化的地方。  

• 「找到並購買一件藍色的襯衫」
  👉 這樣的任務能幫助我們了解整個購物的流程中，對受測者是否輕鬆、能不能找到特定的商品、有沒有什麼地方是我們有所忽略的。

總結來說，規劃「貼近真實場景」的任務能幫助我們去觀察他們操作過程的痛點。

3. 招募受測者

理想情況下，參與者應該符合你的目標族群。根據 Nielsen Norman Group 的研究指出：5 位使用者就能發現 85% 以上的核心問題，所以並不需要過度追求大樣本。如果有明確的目標族群，則每個族群各找 4 位受測者即可。

但現實中，專案常會因為時間緊迫 或 成本不足，只能先找公司內的同仁來測，要注意的是請找非專案同仁甚至是非相關部門同仁，或是親朋好友，而不是專案成員，因為他們太熟悉產品或帶有預設立場，會讓測試會失去效果。

4. 執行測試

測試過程中，研究員不應過度干預，而是觀察、記錄，並鼓勵受測者邊操作邊說出心裡的想法（ 放聲思考 ）。
而在測試中也要盡量模擬真實操作情境，像是在手機上測手機介面，而不是電腦模擬，這樣受測者的行為會更接近實際狀況。

在測試後，讓受測者填寫 SUS 量表，並透過簡易訪談了解受測者操作時遇到的問題與感受。

5. 分析結果

整理觀察到的行為：

• 受測者在哪一步卡住？
• 他們的表情、語氣透露什麼？
• 出現最多次的困難點在哪裡？

結合簡易訪談、SUS量表以及把前面提到的指標( 完成率、完成時間、錯誤率、滿意度 ) 轉為數據指標作為分析的一環，最後，將這些洞察與數據轉化為具體的設計改善建議。

常見的測試方法

1. 實體測試

研究員與受測者實際見面並待在同一個空間進行測試，能即時觀察與追問，適合需要深入觀察操作細節的情境。

2. 遠端測試

受測者透過螢幕共享，研究員在線上觀察。好處是彈性高，能找到更多地域不同的受測者，但缺點是可能會因為網路問題，畫面會有延遲的狀況而沒辦法及時與受測者當下操作的表情同步，甚至可能會有直接斷線的狀況

3. 游擊測試

研究員到咖啡廳或公共場合，隨機找人測試，通常不會是精準的目標族群，但能快速取得真實反饋，因為測試對象不是精準的受測者，測試結果可能會比較粗略，適合用來抓「大方向問題」。不過研究員可能需要具備被人拒絕的勇氣就是了。🤣

為什麼易用性測試很重要？

想像你設計了一台自助點餐機：

在設計師眼中，流程超簡單：點餐 → 確認 → 付款。
但實際測試後，發現有使用者找不到「餐點特製」的按鈕，因為按鈕位置不明顯甚至根本沒有設置。
也有人付款後，以為系統還在處理中，因為付款成功的訊息設置在畫面的角落且三秒就自動消失，很容易被使用者忽略。

這些問題如果沒有經過易用性測試，很可能要等到實際店家大排長龍、顧客抱怨時才會浮現。

📌 總結

易用性測試不是「上線前才驗收」的最後步驟，而應該貫穿在設計過程中。只要持續測試、持續修正，就能避免產品陷入「我們以為很好，實際卻不好用」的窘境。

總結來說：測試是設計不可或缺的一環，易用性測試不是測試受測者的智力，而是測你的設計是否符合使用者的行為。

下一篇，我們會深入探討 「如何規劃並執行一場有效的易用性測試」，將觀察轉換成可執行的設計改善。