RWD 驗證的數字只告訴你版面有沒有破，斷點紀錄才告訴你使用者在哪裡放棄。這篇是寫給剛接手網站維運的新人的教學：從為什麼分數會騙人開始，一步步建立一份團隊都看得懂、修完可以回頭驗收的斷點清單。
RWD 驗證工具給的是「版面是否符合規則」的答案，而不是「使用者能否完成任務」的答案，這兩件事經常不一致。你可能跑過行動裝置相容性檢查、看過 Lighthouse 的無障礙與效能分數，全部都在綠色區間，但 GA4 裡手機版的表單送出率仍然只有桌機的一半左右。
原因通常藏在工具不會檢查的地方：日期選擇器在某些手機瀏覽器上跳出系統鍵盤蓋住送出按鈕、浮動客服按鈕剛好擋住電話欄位、橫向滑動的方案比較表讓人以為只有三個方案。這些都不會讓版面「破掉」，所以分數不會扣，但使用者就是在這裡離開。新人最容易犯的錯，是把分數當成驗收標準，然後在週會上報告「RWD 已通過」，接著轉換問題就被推給廣告或文案。
分數和斷點之間的落差，來自兩者問的問題不同。自動化工具的邏輯是逐條比對規則：文字是否過小、點擊目標是否太近、內容是否超出視窗寬度。這些規則很重要，但它們都是靜態檢查，只看頁面載入完成那一刻的樣子。真實使用者則是動態的：他會捲動、點開下拉選單、切換橫直向、被彈出視窗打斷、在輸入到一半時切去看訊息再回來。斷點幾乎都發生在這些動作之間，所以你需要另一套紀錄方式，專門捕捉「操作過程」裡的問題。
在這份教學裡，斷點指的是使用者在某個裝置條件下，無法用合理的操作完成預期任務的那一刻，而不是 CSS 裡的 breakpoint 寬度設定。兩者名稱相同，意義完全不同，團隊溝通時最好先講清楚。
一個斷點至少要能回答四個問題：在什麼寬度或裝置條件下發生？使用者正在做哪一步？他嘗試了什麼操作？結果是什麼？如果只寫「手機版表單怪怪的」，工程師無法重現，設計師也不知道要改哪裡，這樣的紀錄等於沒記。
舉一個合格的例子：「寬度三百九十左右的安卓手機，系統字體放大一級，在聯絡表單填完姓名後點電話欄位，系統數字鍵盤升起，送出按鈕與隱私同意勾選框被鍵盤完全遮住，使用者向下捲動時頁面會彈回原位，無法勾選。」這段話很長，但工程師看完就能重現，設計師也知道問題在表單底部的固定定位。寫斷點的原則是寧可囉嗦，也不要讓下一個人猜。
建議用一張共用試算表記錄所有斷點，欄位固定，不要讓每個人自己發明格式。以下是我們在網站健檢時常用的欄位：
其中最常被省略的是「是否開啟放大字體」。不少四十歲以上的使用者會把系統字體調大，這時按鈕文字換行、欄位標籤被截斷的問題會大量出現，而測試人員自己的手機通常是預設字體，永遠看不到。
斷點不是一律平等，影響程度要依「是否阻斷任務」而不是「看起來多醜」來分級。我們常用的分級如下，數字區間為示意，可依網站流量調整：
分級時再加一個乘數：這個頁面在該裝置條件下的流量佔比。一個第二級斷點若出現在佔手機流量四成的主要著陸頁，優先順序可能高於只出現在冷門頁的第一級斷點。讓數字和嚴重度一起決定排序，會議上就比較不會陷入誰的主觀感受比較重要的爭論。
新人常會問：那第三級的問題是不是可以不管？答案是不要刪除，只是不排進本週。第三級問題的價值在於累積，當同一個頁面出現五六個第三級瑕疵，使用者的整體感受就是「這家公司不太專業」，這種不信任感會在後面的業務洽談裡付出代價。建議每季挑一個頁面，把它所有的第三級問題一次清完，效果通常比零星修補明顯。
斷點不會自己出現在報表裡，需要定期安排有人真的拿手機走完關鍵任務。一次巡檢可以這樣安排：
找「沒參與開發的人」這點非常關鍵。做網站的人知道按鈕在哪裡，會下意識繞過問題；行政同事、業務，甚至剛到職一週的新人，往往最能暴露真實斷點。
另外要提醒，錄影時請記得關閉通知並使用測試用資料，不要用真實的客戶姓名或電話填表，以免測試資料混進正式的詢問名單，造成業務誤判或個資外流。若表單會串接客戶管理系統，最好先和工程確認有沒有測試模式，或者約定一個固定的測試關鍵字，讓後台可以自動排除這些紀錄。
斷點修完之後，要用數據確認使用者行為真的改變，而不是修完就結案。具體做法是在紀錄表的驗收欄位裡，預先寫下要觀察的指標與期間，例如「修復後四週，手機版方案頁到諮詢表單的點擊率是否接近桌機的七成以上」。
如果指標沒有改善，不代表修錯了，可能是還有第二個斷點排在後面。這時回到紀錄表，看同一個任務是否有其他未處理項目。銘望顧問所在做企業網站健檢時，最常看到的狀況是團隊修了最明顯的一個問題，就以為轉換低是其他原因，結果真正的阻礙還在下一步。
斷點紀錄表很依賴人工巡檢，對於頁面數量上千的大型網站，不可能每頁都走一次，只能聚焦在高流量與高價值任務。另外，少量測試者能發現明顯問題，但無法代表所有使用者，對於極少數裝置的問題，仍需要搭配錯誤追蹤工具或使用者回報。最後，這份表只處理「能不能完成」，至於使用者願不願意完成，屬於內容與提案的問題，要用別的方法處理。