AO2 / INSIGHTS — 把知識變成下一步

手機詢問任務測試：找到入口到完成送出

READING INDEX

先理解問題，再選擇方法。把值得採用的一步，帶回日常工作。

AO2 FIELD GUIDE · N065 · WordPress 與轉換體驗

手機詢問任務測試從一個真實需求出發，觀察訪客找入口、理解欄位、修正錯誤及確認完成的過程。附測試腳本與問題紀錄表，區分介面阻礙、技術故障與需求不明。

手機上的聯絡按鈕存在，不代表訪客能找到、看懂並成功使用。測試應從「他想完成哪件事」開始，走過閱讀、開選單、填資料、修正錯誤與確認回覆方式；把卡住的位置留下，才知道先修按鈕、文案還是系統。

手機詢問任務測試，不從「請點聯絡我們」開始

如果主持人先告訴受測者按哪個按鈕，測到的是照指令操作，不是入口是否容易找到。任務可寫成：「你想確認感測器能否用於戶外路燈，手上有安裝環境與預計數量，請找到能開始討論的方法。」先給工作目標與已知條件，保留他自行選路的空間，不把網站選單名稱寫成提示。

主持式可用性測試，是觀察實際或潛在使用者完成具體任務。應用到企業網站時，先確認角色、裝置與測試範圍，再記錄操作和想法。測試者不必懂網站架構；他是否知道下一步要做什麼，才是需要觀察的事。內部工程師已熟悉畫面，不能完全代替第一次接觸的訪客。

假想訪客在設備現場拿手機看網站。大標題很完整，但需求討論藏在折疊選單，頁底提示框又蓋住按鈕。這像建築外牆有地址，走到門口卻看不見門把。解法可能是調整入口和遮擋，不是再把圖片壓小。先記錄他在哪裡停住、嘗試了什麼，才能判斷。

門牌對應內容辨識，門把是可以執行的控制項，遮擋則是介面衝突。這是假想設計情境，只說明任務包含多段，不能用來判定所有故障。如果網站沒有回應，或送出後出現伺服器錯誤，仍須查技術紀錄；不要把所有失敗都歸給使用者不熟悉。

從實際入口頁開始，不直接打開聯絡表單。保留裝置、瀏覽器、螢幕方向、放大狀態與必要的網路條件。請受測者邊做邊說，主持人先不教他；必須提示才能前進時，要記錄提示內容。協助後完成和完全獨立完成，不應在報告中合成同一種結果。

採用去識別測試資料，先確認送出是否會寄通知、建立商機或啟動其他流程，在受控環境或約定窗口演練。成功不是手指按到送出，而是能辨認資料已被接收。必要時由負責人核對後端紀錄，不能把畫面動畫或按鈕變灰當作唯一證據。

「表單很難用」無法直接交辦。改成具體觀察：反覆開服務選單仍沒找到入口；不知道型號可填未知；放大後錯誤提示離欄位太遠；鍵盤打開時按鈕被遮住。先寫位置與動作，再列可能原因，不把猜測寫成已確認的根因。

觸控尺寸與間距可參考 W3C 說明，但單一尺寸通過不代表整個任務易用，也不等於全面無障礙驗收。手機以外仍要考慮鍵盤、輔助科技與不同操作能力。使用這些方式的人應納入後續測試，不能只用桌面縮小視窗代替所有裝置。

優先處理無法完成、資料遺失及誤判成功的問題，再處理增加負擔的文案與路徑。每項指定負責人和驗收條件，例如「錯誤時保留其他欄位，焦點能到達問題欄，修正後可繼續」。不要只留「優化手機版」或「按鈕明顯一點」這類難以核對的工作。

修正有沒有用，要回到原本卡住的任務確認。保留環境與改動版本，重做一般送出、必要欄位缺漏及中斷後恢復。少量任務觀察可以指出阻礙，不能推算所有訪客的失敗率；把發現當改善依據，另以定義一致的正式資料觀察影響。