網站專案進入尾聲時，最常見的情況是大家把注意力放在版面是否「看起來完成」，卻忽略真正影響營運的細節：聯絡表單是否真的寄得到、手機上的按鈕是否好按、管理權限是否已交接。驗收不是找設計師挑錯，而是確認網站能在真實情境中完成它該做的事。
先依網站目標安排驗收情境
不要從首頁一路往下看，而是從訪客任務出發。若網站的主要目的為取得詢問，就模擬一位第一次認識品牌的訪客：從搜尋結果進入服務頁、閱讀案例或常見問題、填寫表單，再確認公司是否收到通知。
可先列出三到五條最重要的路徑，例如：
- 了解服務內容後預約諮詢
- 從產品頁找到規格或下載資料
- 在手機上取得地址、電話或營業資訊
- 會員登入後查看限定內容
每一條路徑都要記錄起點、預期動作與成功結果。這樣比起籠統地說「網站要順」，更能找出卡住訪客的環節。
內容與連結要用公開視角核對
上線前請由不熟悉專案的人閱讀重要頁面。內部人員容易因為熟悉背景，而忽略縮寫、過時服務名稱或說明不足的圖片。特別要檢查公司名稱、聯絡方式、服務範圍、營業時間與檔案版本是否正確。
同時逐一確認導覽列、頁尾、按鈕、橫幅及社群連結。測試時不要只看連結有沒有反應，也要看目的地是否符合按鈕承諾。例如「立即詢問」不應帶到需要再翻找的首頁；「下載型錄」也不應取得舊版檔案。
用真實設備測試操作與表單
桌面電腦上的良好畫面，不保證手機也容易使用。至少以不同尺寸的手機實機檢查主要頁面，留意文字是否過小、選單能否關閉、固定按鈕會不會遮住內容，以及橫向滑動是否異常。
表單則要以真實信箱送出測試資料，確認以下事項：
- 必填欄位提示是否清楚，錯誤訊息是否指出問題位置
- 成功送出後是否有明確回應，不讓使用者重複送件
- 通知信是否寄到負責信箱，寄件內容是否足以後續聯絡
- 垃圾郵件匣是否收到信件，以及附件或特殊字元是否正常
若表單會串接客戶管理工具或試算表，也應確認欄位是否正確對應，而不是只測試網頁出現成功訊息。
把管理權限與復原資訊列入交接
網站公開後需要持續更新，因此驗收文件應包含管理後台、網域、主機、寄信服務及分析工具的管理責任。帳號不宜只綁在單一承辦人的個人信箱；應指定公司可管理的主要帳號，並確認多人異動時的交接方式。
此外，請詢問目前的備份位置、還原聯絡窗口，以及測試環境和正式網站的差異。這些資訊未必每天會用到，但在更換人員或網站出現問題時，會決定處理速度。
將問題分級再決定上線時程
驗收發現問題不代表一定要延後上線。可區分為會阻斷任務的問題、影響理解或品牌觀感的問題，以及可於後續優化的項目。像是表單無法送出、電話錯誤、重要頁面無法開啟，應在上線前修正；細微間距則可排入下一輪調整。
這種分級能讓團隊在品質與時程間做出有依據的判斷，也能避免所有意見混在一起，最後沒有人知道該先處理什麼。
今天就能做的事
- 選出三條最重要的訪客任務，逐步完成一次並記錄結果。
- 用兩支不同尺寸的手機測試首頁、服務頁與聯絡表單。
- 將所有管理帳號、負責人與續約資訊整理到公司可存取的文件中。
- 把驗收問題分成「上線前必修」與「後續優化」，指定處理期限。
