每個欄位都要有下一步用途
| 欄位 | 何時先收集 | 設計檢查 |
|---|---|---|
| 聯絡方式 | 首次查詢已需要聯絡對方時。 | 按實際跟進方式要求一種合適渠道；唔預設電話同電郵永遠都要必填。 |
| 服務類別 | 需要分派或提供不同建議時。 | 選項使用客戶理解嘅名稱，提供無法確定時嘅選擇。 |
| 公司或網站 | 會影響方案判斷時。 | 若個人或未有網站亦可使用服務，容許選填或說明不適用。 |
| 預算與時程 | 確實會用作合作篩選時。 | 交代用途；可以用範圍與「未確定」選項，避免要求無根據嘅精確數字。 |
呢個表係規劃示例，並非所有網站都要採用同一組欄位。逐項問：移除後，團隊是否仍能安排下一次有效溝通？若答案係可以，考慮改為選填、延後收集或移除。
標籤、提示同手機輸入要配合
- 每項輸入保留可見名稱，唔只用輸入後就消失嘅 placeholder；標籤亦要在程式上對應控制項。
- 在輸入前標明必填及選填，格式或限制放喺欄位附近。
- 電話、電郵與網址使用相應輸入類型，並按資料用途設定自動填寫；電話格式應容許合理嘅區號及分隔符號。
- 避免要求使用者重新輸入已知而且仍有效嘅資料；敏感資料只在確有必要及有適當處理流程時收集。
- 提交前提供實際資料用途及私隱政策連結；如有不同用途嘅選擇，文字同控制項要分清楚。
四種狀態都要設計
| 狀態 | 使用者應該知道甚麼 |
|---|---|
| 尚未提交 | 要填甚麼、哪些必填，以及按鈕會做甚麼。 |
| 輸入錯誤 | 指出具體欄位與修正方法，例如「請填寫可接收回覆嘅電郵地址」，唔只顯示紅框。 |
| 正在處理 | 顯示進度狀態，減少重複提交；唔在尚未確認收到前宣稱成功。 |
| 已收到或失敗 | 成功時交代下一步；失敗時保留可安全保留嘅輸入，提供重試或替代聯絡方式。 |
錯誤及成功訊息需要讓鍵盤和輔助技術使用者察覺。測試時唔只看訊息有冇出現，亦要確認焦點位置、訊息內容及修正後能否繼續完成流程。
量度提交率前，先定義分母同「成功」
可以分開記錄表單曝光、開始填寫、後端確認收到及後續合資格查詢。若使用「成功收到數 ÷ 表單曝光數」，曝光嘅定義、重複提交處理及統計期間都要固定，先可以比較版本。唔好以提交按鈕點擊直接代替成功收到。
分析事件只記錄必要嘅事件與分類；姓名、電話、電郵及自由輸入內容唔應放入分析事件或追蹤網址。若需要串接 CRM，另外定義授權、資料欄位及識別方式。
交收時實測八個情境
- 正常填寫後，確認使用者見到成功訊息，而接收系統亦收到同一筆資料。
- 漏填必填項，確認提示指出欄位並容許修正。
- 輸入合理但不同格式嘅電話或公司名稱，避免過度限制。
- 填寫長文字、中文、空格及特殊字元，確認資料冇被截斷。
- 模擬連線失敗或接收端錯誤，確認唔會誤報成功。
- 連按提交及重新整理，確認重複名單有清楚處理方式。
- 用鍵盤及手機鍵盤完成流程，確認焦點、標籤及按鈕冇被浮動元件遮住。
- 核對追蹤資料冇直接識別個人嘅內容，並測試同意設定下嘅實際行為。
常見問題
一定要做多步表單嗎？
欄位少而直接時，一頁可能更清楚。只有內容較多、需要按答案分流時先評估分步；保留進度、返回及資料處理說明，並實測整體完成路徑。
WhatsApp 可唔可以取代表單？
視乎客戶習慣及團隊跟進方式。可以提供另一條路，但要分開量度按鈕點擊與實際收到嘅對話，唔好把兩者混成同一種成果。
下一步與延伸閱讀
官方參考與更新說明
本文嘅規劃表、測試步驟及示範情境由 ITOB Group 編輯團隊整理；示例並非客戶成效紀錄。最後實質更新：2026 年 10 月 25 日。
