網站開發流程若只寫「設計、切版、上線」，每個階段完成的定義仍然不清楚。發案方可能以為設計包含手機版與完整文案，供應商卻只安排桌機首頁；雙方到了尾款驗收才發現差距，修改成本自然集中在最後。比較穩健的做法，是把專案拆成能看見、能操作、能留下紀錄的階段成果。
W3C 的 Planning and Managing Web Accessibility把工作整理為啟動、規劃、實作與持續維護，並在規劃階段強調目標、責任、預算資源、既有環境及監測架構。雖然文件主題是無障礙，但這個觀念同樣提醒網站專案：品質不是上線前的一次檢查，而要在需求、分工、實作與後續維運中都有負責人。
第一關：需求不是功能名稱，而是使用情境
需求階段先列出網站的對象、任務、資料與例外。以「森嶼環境學苑」案例來看，設定中有六門課程、梯次與名額狀態、報名流程及「我的報名」查詢。若需求只寫「課程報名系統」，就缺少可開發的規則。階段成果應至少說明：梯次由誰建立、滿額時能否送出、訪客用什麼資料查詢、資料錯誤如何更正，以及管理者需要看到哪些欄位。
這一關的驗收不是看畫面，而是由業務、內容負責人與實際操作人員共同走過情境。每個未決問題要記錄負責人與決定時間。若問題會改變頁面數、資料結構或外部串接，應在排期前處理，而不是先假設開發端會自行補齊。
第二關：先驗內容地圖，再驗視覺原型
網站內容應先變成一張可檢查的地圖：主導覽、頁面名稱、每頁目的、必要素材、內容提供者和更新頻率。接著挑一條最重要、也最複雜的路徑做原型。課程網站可以選「找到課程—選梯次—填資料—完成報名—查詢紀錄」；企業官網則可選「進入服務—查看案例—提出詢問」。
以「曦谷共好教會」為例，案例設定包含聚會、課程、影音、最新動態、課程報名、線上奉獻、無障礙友善版與站內搜尋。這些功能不該在同一張首頁稿一次確認。較可行的做法是先驗收內容分類，再分別走過報名、搜尋與奉獻情境，並確認哪些內容會被搜尋、錯誤時如何返回、手機版如何完成。案例功能只是拆解方法的示範，不代表其他專案必須照搬。
第三關：開發期間用代表資料測試
開發開始後，不要只放「測試標題」與相同尺寸的假圖。選擇最長標題、缺圖內容、已額滿梯次、過期活動及不同權限帳號，才能提早看出版面與規則問題。每次階段展示都留下版本、測試網址、已知限制與待確認項目，避免口頭修正失去追蹤。
W3C 的無障礙評估總覽建議在設計與開發過程中及早、持續評估；它也明確指出，沒有任何單一工具能判定網站是否符合所有無障礙要求，仍需要有知識的人員評估。實務上，自動檢查適合找出部分格式問題，但重要任務仍應由人實際操作。驗收清單可納入鍵盤導覽、頁面標題、標題層級、色彩對比、縮放、字幕與表單標籤等項目，再依網站範圍選擇適用內容。
第四關：上線驗收要在正式環境完成
測試站成功，不代表正式環境一定相同。上線前要建立內容凍結時間與搬移清單；上線後再以正式網址檢查主要頁面、導覽、表單通知、搜尋收錄設定、分析工具、錯誤頁與手機顯示。若網站有外部服務，確認正式帳號與測試帳號已切換，並保存設定擁有人與續約窗口。
移交成果也要具體：網域與主機管理權限、網站後台帳號、程式碼或建置產物的約定範圍、第三方服務清單、備份與還原方式、操作文件，以及問題通報管道。是否必須交付原始碼取決於雙方合約與技術方案，不應從「客製網站」四個字自行推定；若這是必要條件，應在報價階段定義。
用變更單處理延期，而不是靠聊天紀錄
網站延期可能來自新增需求、內容延遲、外部服務等待或缺陷修正，處理方式不能混在一起。每次變更記錄提出日期、原因、影響的交付物、費用與時程、是否取代原需求，以及雙方確認人。若只是修正未符合既定驗收條件的缺陷，就不應和新增功能使用同一個模糊項目。
最終驗收表可依階段回看：需求決策是否完成、內容是否齊全、主要情境是否通過、正式環境是否驗證、權限文件是否移交、仍待處理的項目是否另有期限。把網站開發流程變成一連串小型驗收，目的不是增加文件，而是讓問題在仍容易修正時被看見，避免所有風險堆到尾款與上線日。
