很多網站在電腦上看起來很完整，上手機之後卻開始出現小問題：按鈕太靠近、表單欄位被鍵盤蓋住、付款頁要左右滑、登入後找不到課程、影片可以播但教材下載按鈕點不到。
這些問題不一定會讓網站整個壞掉，卻可能讓使用者停在最重要的步驟。
因此，課程網站的手機版驗收不能只看首頁、字體和圖片，而要用「任務」來測試。
手機版驗收的核心：先問「做不做得完」
UX 驗收最重要的觀念，是從使用者要完成的任務出發。
對課程網站來說，可以先設定四種測試身份：
- 陌生訪客：第一次看到網站，要理解內容並完成報名。
- 準客戶：已經知道課程，要完成付款。
- 新學員：剛買完，要建立帳號、登入並找到課程。
- 舊學員：再次回來，要快速找到上次看到的課程內容。
如果這四種人都能在手機上順利完成任務，手機版才算接近可用。
第一步：用真實手機測，不要只相信瀏覽器手機預覽
電腦瀏覽器的 RWD 預覽很方便，可以先抓版面問題，但它不等於真實手機。
真實手機還會遇到：
- 網址列與瀏覽器工具列佔用畫面。
- 虛擬鍵盤彈出後遮住欄位或按鈕。
- 自動填寫、密碼管理器與付款資訊介入。
- Safari 與 Chrome 的行為差異。
- 觸控誤點、滑動與返回上一頁。
- 網路速度不穩或從 Wi‑Fi 切到行動網路。
正式驗收至少要拿一支 iPhone 與一支 Android 真機走流程，不必蒐集所有手機型號，但不能只看模擬器。
第二步：先測「陌生訪客 → 報名」
免費直播、電子書、候補名單或活動報名，通常是手機最常見的入口。
- 首屏是否能快速看懂這頁在做什麼。
- 主要 CTA 是否明顯，不需要一直往下找。
- 按鈕是否容易點，不會和其他連結擠在一起。
- 表單欄位是否足夠大。
- 姓名、Email、電話等欄位是否叫出合適鍵盤。
- 送出前錯誤是否能在欄位附近清楚看到。
- 送出後是否有明確成功提示或完成頁。
常見的手機表單問題，不是「不能送」，而是使用者不知道哪裡填錯，必須來回上下滑找錯誤訊息。
第三步：付款流程要用手機真的走一次
課程網站手機版最重要的驗收之一，就是結帳。
- 商品或方案頁能不能清楚找到付款入口。
- 結帳欄位會不會被切掉或擠得很窄。
- 鍵盤打開後，下一步按鈕是否仍容易操作。
- 信用卡、轉帳或其他付款方式能否正確顯示。
- 優惠碼、條款與必要說明會不會擋住主要動作。
- 付款失敗時，使用者知不知道下一步怎麼做。
- 付款成功後，有沒有清楚告訴學員接下來去哪裡。
付款完成後還有訂單、帳號與開課流程，可以搭配付款完成後不要斷線：訂單確認、帳號建立與開課通知怎麼接起來一起驗收。
第四步：付款成功後，要測帳號建立與登入
很多課程網站前面都順，問題出在「已經付錢了，卻不知道怎麼登入」。
- 完成頁有沒有清楚說明下一步。
- 帳號是自動建立還是要學員自己設定。
- 密碼設定連結能不能正常開啟。
- 登入欄位是否支援瀏覽器自動填寫。
- 忘記密碼流程能不能順利完成。
- 登入後是否回到正確頁面，而不是又被丟回首頁。
登入失敗時，錯誤訊息也要說清楚。不要只顯示「錯誤」或一串系統代碼，而要讓使用者知道是 Email、密碼、帳號狀態還是連結失效。
第五步：登入後，用新學員角度找一次課程
管理員因為知道網站架構，很容易覺得課程入口很明顯；新學員不一定。
登入後可以做一個簡單測試：不靠記憶、不直接貼課程網址，只從會員首頁開始，看能不能在幾個清楚的操作內找到已購課程。
- 「我的課程」或等效入口是否清楚。
- 目前登入身份是否容易辨識。
- 已購課程與未購課程有沒有混在一起。
- 課程封面與標題在小螢幕上是否容易辨識。
- 沒有權限時，提示是否說明原因與下一步。
第六步：真正打開一堂課，測到影片、教材與進度
課程頁本身也不能只看第一屏。
- 影片能否播放、暫停與全螢幕。
- 橫向／直向切換時版面是否正常。
- 長文字是否容易閱讀。
- 教材下載按鈕是否好點。
- 章節導覽會不會太窄或被固定元件遮住。
- 完成單元、下一課與上一課是否清楚。
- 學習進度是否真的被記錄。
舊學員也要測一次：離開網站後再回來，能不能快速找到上次的課程與進度。
第七步：手機按鈕不是「看得到」就算好用
手機主要靠觸控。按鈕太小、兩個按鈕靠太近，都容易造成誤點。
WCAG 2.2 的 Target Size (Minimum) 對指標輸入提出至少 24 × 24 CSS pixels 或足夠間距的要求，目的就是降低誤觸。
實務驗收時，可以直接用手指操作，不只用眼睛看：
- 主要 CTA 是否容易一次點中。
- 「上一頁／下一頁」是否太靠近。
- 小型圖示是否只有圖、沒有可理解標籤。
- 關閉按鈕、選單與彈窗是否容易點。
- 表單勾選框是否小到常常點不到。
第八步：鍵盤、固定按鈕與手機安全區不要互相打架
手機表單一打開鍵盤，可用高度會立刻變少。如果底部同時有固定 CTA、聊天按鈕或 Cookie 提示，很容易把「下一步」「送出」或錯誤訊息擋住。
驗收時要真的點進每一個欄位，確認鍵盤開啟後仍能看見目前輸入位置，也能順利捲動到下一欄。iPhone 底部安全區、瀏覽器工具列與固定元件也要一起看，避免按鈕貼到螢幕邊緣或被系統介面吃掉。
第九步：不要把重要資訊藏在 Hover
桌機有滑鼠 Hover，手機沒有。
如果價格說明、提示、選單、按鈕文字或必要解釋只有滑鼠移過去才出現，手機使用者可能完全看不到。
驗收時要特別找：
- 只有 Hover 才顯示的說明。
- 只有桌機才出現的選單。
- 手機上被隱藏但其實很重要的文字。
- 固定浮動按鈕擋住底部內容。
第十步：測試錯誤流程，不能只測「一路成功」
真實使用者不會每次都一次成功。
- Email 少打一個字。
- 必填欄位沒填。
- 密碼輸入錯誤。
- 付款失敗。
- 連線中斷後重新整理。
- 按上一頁再回來。
好的錯誤流程要做到三件事：告訴使用者發生什麼、哪裡需要修正、下一步怎麼做。
如果出錯後整張表單全部清空，手機使用者通常更挫折，因為重新輸入的成本比桌機高很多。
第十一步：測「被打斷後回來」，手機使用情境才完整
手機使用者可能在付款前接到電話、切去銀行 App、複製 Email、查看簡訊驗證碼，再回到瀏覽器。
因此要測：
- 切到其他 App 再回來，頁面是否還保留狀態。
- 瀏覽器返回後，已填表單是否合理保留。
- 第三方付款完成後能不能正確回到網站。
- 登入或驗證完成後，是否回到原本想去的課程。
- Session 過期時是否有清楚重新登入方式。
使用者被打斷本身不是錯誤；如果一被打斷就得整段重來，才是手機流程的摩擦。
第十二步：慢網路也要測，尤其是付款與課程頁
手機不一定一直有穩定 Wi‑Fi。
- 按鈕按下後有沒有 Loading 或狀態提示。
- 使用者會不會因為沒反應連按兩次。
- 付款是否可能重複送出。
- 影片或教材載入失敗時有沒有提示。
- 重新連線後，表單資料會不會全部消失。
「系統正在處理」要讓人看得到，否則使用者很容易以為沒按到。
字體放大後也要能用，不要只測預設大小
有些使用者會放大瀏覽器字體或使用系統較大的文字顯示。手機畫面本來就窄，文字一放大，更容易出現按鈕被擠掉、標題截斷、表格超出畫面或固定區塊遮住內容。
驗收時可以把文字放大，再走一遍主要頁面。重點不是所有版面都維持完全相同，而是主要資訊仍讀得到、操作元件仍點得到、頁面不需要水平拖動才能完成核心任務。
不要只測一支手機，至少做一個小型測試矩陣
| 環境 | 至少測什麼 |
|---|---|
| iPhone + Safari | 報名、付款、登入、上課 |
| Android + Chrome | 報名、付款、登入、上課 |
| 較小螢幕 | 按鈕、表單、固定元件、文字換行 |
| 較慢網路 | Loading、重試、付款、影片與教材 |
如果主要客群有明顯裝置比例，再把真實流量資料加入測試優先順序。
問題要分嚴重度：先修會擋住任務的，再修漂亮度
UX Heuristics 常用嚴重度來排優先順序。手機驗收也可以簡化成四級：
| 嚴重度 | 例子 | 處理優先 |
|---|---|---|
| 4｜阻斷 | 不能付款、不能登入、買了卻進不了課程 | 立即修 |
| 3｜重大 | 表單常失敗、主要 CTA 被遮住、錯誤後無法繼續 | 上線前修 |
| 2｜次要 | 需要多滑幾次、文字換行不漂亮 | 排入改善 |
| 1｜外觀 | 小間距或輕微視覺不一致 | 有餘裕再修 |
這樣不會因為一個小圓角花很多時間，卻漏掉「手機付款按鈕被鍵盤遮住」這種真正影響成交的問題。
驗收不要只做一次，每次重大變更都要重跑核心流程
網站剛完成時手機版正常，不代表半年後還正常。
- 更換主題或頁面建構器。
- 修改報名頁或結帳頁。
- 更新會員、課程或 WooCommerce。
- 更換金流。
- 新增快取、CDN、安全或 Cookie 工具。
- 搬主機或改 PHP 版本。
如果剛做過搬家或大型系統調整，也可以搭配課程網站搬家後要測什麼？一起驗收。
一張手機版完整驗收清單
- 首頁與主要銷售頁沒有異常橫向捲動。
- 主要 CTA 容易找到、容易點。
- 報名表單可完整輸入與送出。
- 錯誤訊息出現在正確位置。
- 結帳欄位與付款方式可操作。
- 付款成功頁下一步清楚。
- 帳號建立與密碼設定正常。
- 登入與忘記密碼正常。
- 會員能找到已購課程。
- 影片、文字、教材與課程導覽正常。
- 課程進度能保存。
- 錯誤與慢網路情境有清楚回饋。
- 切 App、返回上一頁後能合理恢復。
- 重要按鈕與連結不靠 Hover。
- 固定元件不遮住重要內容。
- 文字放大後核心任務仍可完成。
- 至少用 iPhone Safari 與 Android Chrome 實測。
常見問題
用 Chrome 開發者工具看手機版就夠了嗎？
不夠。開發者工具適合先檢查 RWD，但真實手機還會遇到鍵盤、瀏覽器工具列、觸控、自動填寫、付款與裝置差異，正式驗收仍要用真機走流程。
手機版最重要先測哪一段？
如果網站正在招生，優先測報名與付款；如果已經有學員，再加上登入、找課與上課。核心原則是先測會直接影響成交與交付的流程。
是不是每一款手機都要測？
不需要。至少覆蓋主要的 iPhone Safari、Android Chrome，再補一個較小螢幕與較慢網路情境，已經能抓到大部分重大問題。
手機按鈕多大才安全？
WCAG 2.2 的最低目標尺寸規範是 24 × 24 CSS pixels 或符合間距例外。實務上主要 CTA 通常會做得更大，重點是容易點、不誤觸。
付款頁不是我自己做的，也要測嗎？
要。即使是第三方金流頁，使用者仍然是從你的流程進去。要確認跳轉、付款、取消、失敗與返回網站後的狀態都正常。
手機版驗收多久做一次？
至少在正式上線前做完整驗收；之後遇到結帳、會員、課程、主題、頁面建構器、主機或重大外掛更新時，再重跑核心流程。
手機版驗收的標準，是學員能不能順利完成整段旅程
手機版好不好，不只看畫面漂亮、字有沒有跑掉。
重要的是：使用者能不能從第一次看到頁面開始，完成報名、付款、建立帳號、登入、找到課程，再順利開始學習。
把驗收從「看版面」改成「走任務」，再加上錯誤、慢網路、中斷恢復與真實裝置測試，才比較容易在學員遇到問題之前先把摩擦找出來。
如果通知信是流程的一部分，也可以再看課程通知信寄不到怎麼辦？，把付款後的 Email 與登入通知一起納入手機驗收。
參考資料：
W3C Web Accessibility Initiative｜Web Content Accessibility Guidelines (WCAG) 2.2。
W3C WAI｜Understanding Success Criterion 2.5.8 Target Size (Minimum)。
Steve Krug｜Don’t Make Me Think。
Jakob Nielsen｜10 Usability Heuristics for User Interface Design。