教育品牌規劃預約網站製作時，最容易把課程報名寫成一句「學員填表後送出」。這句需求無法回答許多實際問題：哪些欄位真的必填、手機號碼能否含空格或連字號、錯誤後先前輸入會不會消失、付款前是否能再確認，以及使用者看到「完成」時，後台是否也確實建立報名。
報名表的價值不是收集最多資料，而是讓合適的人用可理解、可修正的方式完成任務。發案時應把欄位、驗證、狀態與通知分開定義，再用錯誤情境驗收；否則畫面看似完整，真正招生時才會發現學員卡在格式限制，或團隊收到無法辨識的重複資料。
先證明每個欄位都有必要
課程、梯次與人數通常應由前一步選擇帶入，避免使用者重複輸入。聯絡資料也要逐欄說明用途：電子郵件是收報名確認，電話是臨時異動聯絡，還是兩者都會用於行銷？若某資料只在特殊課程需要，就在該情境出現，不要讓所有人都填一張最長表單。
必填與選填不能只靠顏色區分。欄位要有可讀名稱，格式要求應在輸入前就能看見，例如日期格式、字數限制或同行者填法；錯誤後也要保留已正確完成的內容。驗收文件可列出每個欄位的名稱、用途、資料型別、是否必填、可接受格式、錯誤訊息與後台對應欄位，讓設計、前端與營運讀的是同一份規則。
W3C 的 Validating Input說明，必填控制項應由標籤清楚指出，常見資料可使用合適的輸入型別；同時提醒驗證要包容同一資料的不同合理格式，例如電話可能有不同分隔方式。文件也指出前端驗證可改善使用體驗，但仍需要伺服器端驗證，因為前端檢查可能被略過。
因此，課程報名不應把「0912-345-678」判成錯誤，卻接受一串看似符合長度但實際不可用的資料。比較穩健的做法是先容許合理輸入，再於儲存時正規化；無法自動判斷的內容標成待確認，而不是偷偷改寫學員原意。
錯誤訊息要帶人回到可修正的位置
只在送出按鈕旁顯示「資料有誤」沒有指出是哪一欄、錯在哪裡，也無法讓鍵盤或輔助技術使用者快速抵達問題。W3C 的 User Notification建議，表單送出後應明確告知成功或失敗；錯誤摘要要引用對應欄位名稱、用容易理解的文字描述問題、提供修正方法，並可連回相應控制項。動態顯示的錯誤也要以適當方式通知輔助技術。
可把驗收拆成三層：欄位旁立即說明具體錯誤，表單頂端列出錯誤總數與可跳轉清單，焦點則移到能理解結果的位置。顏色、圖示可以輔助，但不能成為唯一訊號。像「格式錯誤」應改成「電子郵件需要包含 @ 與網域」；像「日期無效」則應說明可接受格式，而不是讓使用者反覆猜測。
還要測試伺服器回傳的錯誤。若送出時該梯次剛好額滿，訊息要保留其他輸入，清楚說明名額已變動，並提供改選梯次或加入候補的下一步。這種業務衝突不能假裝成網路錯誤，更不能建立一筆沒有有效梯次的報名。
送出前後都要有可核對的狀態
涉及費用、特殊資格或多人同行時，可在最終送出前顯示確認摘要，讓使用者核對課程名稱、梯次、姓名與聯絡方式。返回修改後，摘要必須同步更新。按下送出後要防止連點造成重複報名；若網路逾時，重新送出同一請求也不應無條件新增第二筆。
完成頁至少顯示報名識別、課程與梯次、目前狀態，以及下一步會透過哪個管道通知。畫面成功、確認信寄出與後台建檔是三件不同的事，系統應保存各自結果。郵件暫時失敗時，已成立的報名不該變成不存在；營運端需要能重送通知，也能看出學員是否其實已完成報名。
用環境課程展示案例跑一次完整驗收
森嶼環境學苑展示案例包含六門環境課程、梯次與名額狀態，也提供「我的報名」查詢。這是網站展示作品，不是實際教育客戶的成效資料；它適合拿來建立驗收劇本，檢查課程內容、梯次選擇、表單與後續查詢是否接成同一條路徑。
第一輪以一般學員選擇尚有名額的梯次，故意漏填必填欄位、輸入帶連字號的電話，再修正電子郵件。系統應保留正確欄位、指出具體問題，成功後只建立一筆報名，並讓「我的報名」查到相同識別與狀態。
第二輪由兩個裝置同時搶最後一個名額。其中一方先成立後，另一方應在送出時收到名額已變動的業務訊息，不能只因兩邊進入表單時都有名額就超收。第三輪模擬送出後網路中斷再重新整理，確認不會產生重複報名，使用者仍能用既定方式找回結果。
把驗收證據交給招生與客服
上線前應保存桌機、手機與鍵盤操作的測試結果，涵蓋空白、錯誤格式、超長內容、名額衝突、重複送出、通知失敗與查詢找回。每個案例記錄預期畫面、後台狀態與通知結果，讓招生人員不必從技術紀錄猜測學員到底有沒有報上。
課程報名系統的完成標準，不是按鈕能送出，而是使用者知道要填什麼、犯錯時能修正、送出後能確認，營運端也能把每個畫面結果對回唯一報名。把這些條件寫進預約網站製作規格，才能減少招生期間最難追查的「我有送出，但你們沒收到」。
