我為何執行易用性測試？
執行易用性測試，不僅是為了把關產品操作層面的體驗品質；回顧過去在敏捷團隊中執行測試的經驗，我認為它更能為「產品、團隊與專案管理」帶來以下三大價值：
我的測試策略
根據 ISO 9241-11 的定義，易用性的三大核心是「有效性」、「效率」與「滿意度」。這是業界公認的完整框架；而在我自己執行測試的實務經驗中，我發現把更多的確認焦點放在受測者的「理解程度」上，往往能讓測試產出更切中我需要的洞察。這樣的調整，主要來自我實務中的兩個觀察：
- 「理解程度」比「滿意度」更容易設計出精準的提問
- 滿意度著重於受測者的情緒反應，而在「被觀察」且「有時間壓力」的測試情境中，受測者往往難以當場精確地組織語言、說明自己情緒的來由。相較之下，針對「理解程度」設計的提問（例如請受測者用自己的話解釋剛完成的操作），能讓我更直接地定位到他在哪個環節產生了認知落差。
- 受測者的文化脈絡：日本的禮節文化
- 我的受測者以日本使用者為主。在日本的文化脈絡中，人們往往顧及禮節，傾向不在陌生人面前直接說出負面評價。即便測試前已強調可以直言不諱，受測者仍極少主動表達不滿 —— 這讓「滿意度」的提問在我的實際情境中較難獲得有效資訊，也讓我更倚重從「理解程度」切入。
我對「理解程度」的提問框架
- 操作意義的理解：受測者能否明確陳述剛剛完成的操作內容及其目的。
- 介面語意的理解：受測者是否真正理解畫面中的 UI 元素與專有名詞（如文案、標籤）。
- 情境脈絡的理解：在給定的任務情境下，受測者是否明白「為何」必須執行這個任務。
只要在測試過程中，客觀記錄操作的「有效性」與「效率」，並透過提問核實「理解程度」，我們就能準確定位受測者在哪個節點遭遇挫折或認知問題，並將這些洞察用於設計優化。當使用者的「理解程度」與「操作效率」獲得保障，功能上線後的「滿意度」自然水到渠成。
我會在何時執行易用性測試？
什麼狀況下會啟動？
易用性測試需要投入相應的時間與人力，因此並非每個功能都會執行。當新功能牽涉的範圍廣泛、體驗流程複雜，且需要驗證使用者是否對系統運作具備「正確的預期與心智模型」時，我會與團隊討論是否執行易用性測試。
我的測試流程
我的測試流程可分為三個階段：從「準備」、「執行」，到「分析與落地」。
🗂 準備階段（步驟 1–5）
1. 定義測試目的
雖然易用性測試的目的與核心評價觀點已經很明確，但為了對齊團隊對測試的認知，我仍會在此階段明確定義該功能「被有效且流暢執行的理想狀態」，作為整場測試的評價基準。
2. 拆解測試目的
我會將高階的測試目的，拆解為具體可被評估的小目的。拆解時依循前述的觀點：「有效性」與「效率」對應受測者的行為操作，「理解程度」則對應受測者的認知。拆解完成的小目的，將作為後續撰寫測試腳本的核心骨幹。
3. 撰寫測試腳本
- 設計任務
- 將拆解後的小目的轉化為具體的測試任務。每個任務皆包含「情境」與「指示」：情境旨在賦予操作脈絡，幫助受測者帶入真實使用者的心理狀態；情境建立後，再給予明確的指示，引導受測者開始操作原型。
- 設定任務的達成條件
- 明確定義任務在「行為操作面」的成功標準。由於完成同一個任務可能存在複數路徑或方式，需盡可能在達成條件中涵蓋所有可能路徑，並將不同路徑間的「效率差異」納入評估考量。
- 設計任務完成後的理解程度提問
- 針對需要確保認知對齊的關鍵任務，預先設計追加提問。即便受測者在操作面上沒有展現出「有效性」或「效率」的阻礙，我也會透過提問核實：他們是否真正理解該操作的背後意義。
4. 執行前測
撰寫好的測試腳本難免存在預想之外的盲點，因此在正式測試前，我會透過內部前測進行除錯。通常我會檢視以下四個面向：
5. 招募受測者
我在招募易用性測試的受測者時，通常採取務實且彈性的篩選策略：
- 理想上，受測者應對齊目標使用者
- 根據該功能或產品的目標使用者制定篩選條件，期待受測者能反映目標使用者的真實使用情況。
- 實務上的權衡與最低招募條件
- 實務中，符合目標使用者條件的受測者稀少，因此我通常會將這類珍貴的受測者，優先保留給需要深度挖掘價值觀與需求的「概念測試」或「生成式訪談」。
- 相較之下，易用性測試側重於檢驗介面邏輯與資訊架構。因此，我會將招募底線設定在「受測者具備一般電子產品的基本操作能力」 —— 藉此排除因「不熟悉電子產品」而產生的假性易用性問題，讓測試能聚焦於真正的設計盲點。
🎬 執行階段（步驟 6）
6. 執行易用性測試
- 施測環境
- 依實際狀況採遠距或實體方式進行。遠距測試時，我會引導受測者開啟視訊鏡頭與螢幕分享；實體測試則安排於公司會議室，並架設攝影機與三腳架，完整記錄受測者的螢幕畫面、表情與肢體語言。
- 雙人協作的觀測機制
- 為了兼顧訪談與記錄品質，測試中會進行雙人分工：
- 引導者：根據腳本主導測試、說明任務，並適時追加提問。
- 觀察者：隱身於幕後，專注捕捉受測者的表情、肢體語言、操作狀況與發言，並進行詳實記錄。
- 為了兼顧訪談與記錄品質，測試中會進行雙人分工：
- 推動團隊參與測試
- 我會鼓勵產品團隊（PO、工程師等）共同參與測試。團隊成員可自由登記成為「觀察者」，在第一線感受真實使用者的痛點 —— 這能大幅降低後續修改設計時的溝通成本。此外，若團隊成員有意願挑戰擔任「引導者」，我會提前分享測試腳本、協助他們上場 —— 這能逐步提升整個團隊對於設計的成熟度。
📊 分析與落地（步驟 7–8）
7. 分析易用性測試的結果
- 質性資料可視化與任務評估
- 將受測時記錄的逐字稿，拆解成單一意涵的顆粒度，並轉錄於 Miro 的便利貼上。接著在 Miro 中建立「受測者 × 任務」的分析表格（橫軸為受測者，縱軸為任務），將便利貼對應填入表格中。
- 團隊評估任務結果
- 帶領團隊共同檢視每一格的任務執行狀況，並依據以下標準進行成效判定：
- 🟢有效完成任務：無明顯效率阻礙或認知問題，順利達成任務。
- ⚠️完成任務但有問題：雖最終完成任務，但過程中遭遇明顯的效率降低或認知問題。
- ❌任務未完成：受測者最終放棄，或無法達成任務目標。
- 帶領團隊共同檢視每一格的任務執行狀況，並依據以下標準進行成效判定：
- 分析與定義問題
- 嚴重度計分
- 統計每個任務的表現分數（⚠️ 計 0.5 分／❌ 計 1 分）。透過積分找出「嚴重度」高的任務，優先針對高分任務進行易用性問題分析。
- 親和圖法
- 挑出構成易用性問題成因的關鍵便利貼，進行跨受測者的統合整理，將零散的痛點歸納收斂，把易用性問題明確定義出來。
- 問題修復的優先順序
- 帶領團隊針對已定義的易用性問題進行討論，權衡「修復工時」與「問題嚴重度」，共同決定修復的優先順序。
- 嚴重度計分
8. 設計迭代與交付開發
我會依據前一步定下的修復優先順序，將測試洞察轉化為具體的設計優化提案，並與團隊確認各項優化的執行排程 —— 哪些納入本次開發、哪些排入 Backlog。