網站聯絡表單設計：欄位、錯誤提示與送出回覆怎麼規劃

先定義這張表單要完成的任務

一張首次詢問表單，通常只需要讓接待者能判斷問題並聯絡對方；完整報價資料可以在後續取得。如果把第一次聯絡當成正式需求訪談，訪客就得先回答尚未想清楚的預算、規格與時程。這些答案即使填了，也未必足以作為報價依據。

可以先請實際收件的人完成一句話：「收到這張表單後，我會用哪些資料，決定哪一個下一步？」例如，合作洽詢交給業務，售後問題交給客服。若服務項目不影響分流，也不影響第一次回覆，就不必為了讓表單看起來完整，另外做一長串必選分類。

接著定義完成條件。對一般詢問，可以是資料已被系統接收並留下可供負責人處理的紀錄；若實際流程只有寄信，則要說明如何確認寄送結果及處理失敗。不要先在畫面寫好「我們已收到」，才發現技術端的成功只代表按鈕被點擊。

整體網站目標尚未確定時，可先用網站建置前準備清單釐清主要訪客與任務，再處理表單細節。表單無法替服務頁補完所有資訊；服務範圍、適合對象與合作方式仍應在訪客開始填寫前交代。

做法一：用處理用途決定必填欄位

逐項列出現有欄位，寫上「誰會使用、何時使用、沒填會怎樣」。只有缺少後就無法受理、回覆或正確分派的資料，才有明確的必填理由。只是將來可能用到，可以選填、延後詢問，或乾脆移除；選填欄位同樣會占用閱讀空間。

以下以「透過 Email 回覆的初次專案詢問」為示例。它提供的是判斷方式，不是所有企業都應照抄的固定欄位數。

欄位	本情境的安排	何時需要改變
聯絡 Email	必填，用來回覆	若改以電話處理，應重新決定必要聯絡方式
想詢問的問題	必填，允許簡短描述	若前頁已明確選定單一服務，可帶入情境，避免重問
稱呼	選填，方便稱呼對方	特定申請需要辨識身分時，另行確認用途與規則
電話	選填，說明是否會致電	訪客選擇電話回覆時，才要求提供可用號碼
公司與網站	選填，協助理解背景	若只受理企業服務，先說明資格，再決定必要資訊
預算與時程	可延後詢問，或提供「尚未確定」	確實用於判斷能否承接時，解釋用途並提供合理選項

有條件的必填，比一律要求更能對應任務

假設訪客可以選擇 Email 或電話回覆，可以先問偏好，再要求對應的聯絡方式。選擇電話時，電話欄位出現必填說明；改回 Email 後，不應繼續被隱藏的電話欄位擋住。這種設計需要前後端採用一致規則，不能只在畫面上隱藏欄位。

也不要把「還不知道」當成無效回答。第一次洽詢網站的負責人，可能尚未確認預算範圍；硬選一個數字會讓後續討論建立在錯誤前提。可以讓他選「需要協助評估」，並在下一輪說明估算需要哪些資料。反過來，如果服務確有不可省略的受理條件，就應提早說明，避免收件後才讓對方重來。

用一輪模擬收件檢查欄位是否夠用

準備一筆不含真實客戶資訊的示例，請收件人只看這份資料，說出第一封回覆會問什麼。如果每一筆都缺同一項必要資訊，就考慮加入；如果某欄永遠沒人使用，就確認是否能移除。這個方法能檢查欄位與流程是否相符，但不能據此宣稱刪掉欄位一定提高轉換率。

做法二：把標籤、說明與輸入方式一起設計

每個欄位需要一個填寫時仍看得到的名稱，必要時再加一句用途或格式說明。只把「請輸入 Email」放在輸入框裡，開始打字後提示便可能消失；訪客回頭檢查時，不容易辨識剛才填的是哪一欄。標籤負責說明要填什麼，提示文字負責補充怎麼填，兩者分工清楚就不必寫得很長。

W3C WAI 的欄位標籤教學建議讓標籤與控制項建立關聯。實作時可用 label 的 for 對應欄位 id，讓點擊標籤與輔助科技辨識都有明確依據。單看畫面上有一行字，還不能確認關聯已正確建立。

把模糊的欄位名稱改成可以作答的問題

例如「需求」可以改成「你想解決什麼問題？」並在旁邊提示「可簡述目前狀況與希望協助的事項，還不確定規格也可以先說明」。這比要求訪客一次交出完整專案書更容易理解。若欄位用來選服務，選項名稱也應與服務頁一致，不使用只有內部人員懂的部門代碼。

必填和選填可以直接用文字標示，並在整張表單採用一致規則。星號若有使用，要說明意思；不能只靠顏色區分。標示為選填的欄位，空白時就必須能送出。這些文字也屬於產品功能，需跟驗證規則一起確認。

按鈕可寫「送出詢問」，並在附近交代後續如何聯絡。若實際按鈕只是進入下一頁檢查資料，就應使用「確認填寫內容」等符合動作的文字。需要檢查表單前的引導與服務說明時，可參考行銷文案與行動引導的寫法，讓入口與表單承接同一個任務。

讓手機輸入方便，也容納合理格式

Email、電話與姓名有不同輸入需求。工程實作可選合適的欄位類型，並依MDN 的 autocomplete 說明提供 name、email、tel 等用途提示。這有助瀏覽器辨識欄位，但是否出現合適鍵盤、是否正確自動填入，仍要在實際裝置測試。

電話號碼可能包含國碼、空格或分機；名稱也可能包含英文、空白與較長的組合。規則應依服務範圍制定，不要因一個過度簡化的格式判斷，就拒絕合理的聯絡資料。若只支援特定格式，請在填寫前說明限制，並提供能使用的替代管道。

做法三：寫清楚錯誤，保留已填內容

錯誤訊息至少要讓人知道哪裡有問題，以及如何修正。「資料錯誤」無法告訴訪客是 Email、必填欄位還是系統出了狀況；「Email 格式不完整，請檢查是否包含 @ 與網域」則提供了可執行的檢查方向。措辭應描述目前狀態，不責備使用者。

W3C WAI 的表單通知教學說明，錯誤可同時放在欄位附近與表單上方，並提供前往對應欄位的連結。應讓鍵盤與輔助科技使用者也能找到訊息；只把外框變紅，無法完整交代問題。

遇到的情況	可參考的訊息	功能也要做到
漏填回覆用 Email	請填寫可接收回覆的 Email。	指出該欄，保留其他內容
問題描述空白	請簡述想詢問的問題，幾句話即可。	不要求與受理無關的固定長度
附件超過限制	檔案超過可上傳大小，請改用較小檔案。	顯示實際限制；保留文字與其他有效資料
系統明確拒絕收件	目前無法送出，請保留內容並稍後重試。	提供可用的替代聯絡方式
連線逾時，結果不明	目前無法確認是否已收件，請先保留內容。	依系統能力提供查詢、重試或聯絡途徑

不要在還沒填完時，就把每個字都判錯

訪客剛輸入 Email 的前半段，當然還不是完整地址。可以依欄位特性，在離開欄位或嘗試送出時提示，並在修正後更新狀態。持續閃動錯誤會打斷填寫；完全等到送出後才揭露早已知道的限制，也會讓人白做一輪。驗收時應包含「開始輸入、離開、修正、再次送出」，而不只測空白表單。

前台檢查能提早提醒，但不能取代後端驗證。W3C 的輸入驗證教學明確指出，資料仍需在伺服器端檢查。兩端應接受相同的合理資料；前台說可以、後台卻拒收的情況，會讓訪客不知道還能改什麼。

送出處理中可暫時防止重複提交，並顯示「正在送出，請稍候」。遇到可修正的錯誤後，要恢復能繼續操作的狀態；不能讓按鈕永久停用。這段等待也要能被使用者察覺，避免畫面毫無反應而誘發連續點擊。

狀態未知時，不能直接承諾成功或失敗

使用者按下送出後斷線，可能是請求沒到伺服器，也可能是資料已收到、回應卻沒傳回來。訪客未必能區分這兩種情況，因此畫面不應在固定倒數結束後，自動宣稱「已成功寄送」。只有取得對應的收件確認，才顯示完成。

若系統支援同一筆請求的識別與重複檢查，可以讓重試對應原本的提交，降低重複收件。尚無這項能力時，要在規格中標明，並提供替代聯絡方法；不要讓文案假裝已有查詢功能。重點是讓人保有已填資料，並知道目前有哪些可行的下一步。

做法四：把成功訊息接到實際收件流程

成功畫面應說明已完成的事，以及接下來由誰、用什麼方式處理。可參考英國政府設計系統的完成頁模式：確認完成、交代下一步，必要時提供參考編號與聯絡方法。企業詢問表單不必照搬政府交易頁面，但這幾項資訊能用來檢查訊息是否足夠。

例如，若網站確實將資料存入後台，可寫「已收到你的詢問，服務窗口將透過你填寫的 Email 聯絡」。若團隊已有能遵守的回覆時限，再填入實際工作日與服務時間；未約定前不要先寫「立即回覆」。收到表單也不代表已接受委託、確認預約或完成報價，這些狀態應分別表達。

把保存、通知與回覆分開核對

後台有一筆紀錄，不代表通知信已送達；通知信送出，也不代表負責人已讀取。可以畫出三個交接點：網站接收資料、通知負責人、負責人回覆。每一步都要指定核對位置與責任人。例如由接待窗口查看待處理紀錄，寄信異常則交給網站維護者追查，不能把寄出通知當作案件已有人接手。

如果已保存資料但通知寄送失敗，應由內部看到異常並補處理，而不是要求訪客重新填表。若網站只靠 Email 傳遞、沒有後台紀錄，驗收就更要確認寄送失敗時如何處理，以及誰會查看寄信狀態。這屬於服務流程設計，不能用換一個成功圖示代替。

驗收可使用一筆明確標記為測試的資料，從送出畫面一路核對到受理端，記錄測試時間、識別方式與結果。測試應在團隊同意的環境與時段進行，不拿真實客戶個資當範例，也不讓測試信誤觸正式報價或其他後續作業。

用手機、鍵盤與異常情境驗收

桌面畫面能正常送出，只涵蓋一種順利情境。手機輸入時，鍵盤會占用畫面；長選項、錯誤訊息與固定底部按鈕也可能互相遮擋。請在表單有內容、有錯誤及送出後各看一次，確認狀態變化沒有讓使用者失去方向。

可以從下列任務建立測試紀錄。每筆都寫下裝置與瀏覽器、操作步驟、預期結果、實際結果，以及修正後是否重測。只有「手機版正常」四個字，後續很難知道究竟測過哪些情況。

• 只填必要欄位：能順利受理；所有選填欄位留空都不會擋住送出。
• 切換回覆方式：必填規則隨選擇改變，不被隱藏欄位阻擋。
• 輸入中文、英文長名稱與合理電話格式：內容不被截斷，格式限制與說明一致。
• 留空必填、填錯 Email 再修正：指出正確欄位，修正後能繼續，其他文字仍在。
• 只用鍵盤依序操作：能到達每個欄位、選項與按鈕，看得到焦點位置，也能找到錯誤提示。
• 在受控測試環境模擬慢速連線或中斷：不誤報成功，不清空未確認送達的內容，重試不造成難以辨識的重複紀錄。
• 完成一次有效提交：成功訊息、後台或寄信紀錄、通知與承辦處理方式互相符合。

這份清單是功能驗收起點，不等於已完成所有無障礙或安全評估。如果表單是主要接單管道，還應依實際使用者安排螢幕閱讀器、放大文字與更多裝置測試。由沒參與設計的人照說明操作，也能發現團隊因熟悉流程而忽略的問題。

如何判斷表單調整有沒有解決問題？

先把問題寫成能檢查的假設。例如「訪客不知道電話是選填，改成明確文字後，是否還會詢問一定要留電話？」可以透過操作觀察與實際回饋檢查；「表單太長所以沒有訂單」則同時包含很多未確認原因，不能只刪欄位就認定已解決。

資料足夠時，可以分開觀察開始填寫、驗證錯誤、確認收件，以及後續符合服務範圍的詢問。按鈕點擊不能當作收件成功；同一個人反覆修正，也不能直接解讀成多個潛在客戶。使用分析工具前先確認事件定義，只記錄必要的事件狀態，不把姓名、Email、電話或需求全文放進分析事件或追蹤網址。

若還需要知道訪客來自哪個活動，可延伸閱讀UTM 參數命名與成效判讀指南。來源標記回答「從哪個入口來」，表單紀錄回答「是否確實受理」；兩者搭配仍須有一致的比較條件，不能把活動流量差異全歸因於欄位調整。

改版時保留變更內容與日期，優先處理已能重現的錯誤，再觀察設計取捨。若同時更換廣告受眾、服務方案與表單，應如實記錄；詢問量改變可能有多個原因。低流量網站可以先做任務測試，讓幾位符合客群的人說出疑問，不必用少量送出紀錄硬湊成效結論。

網站聯絡表單設計常見問題

聯絡表單一定要壓到三個欄位以下嗎？

沒有適用所有網站的固定數量。先確認受理與回覆需要哪些資料，再刪除無用途或可以稍後取得的欄位。若服務必須先知道產品型號才能分派，就保留並解釋用途；若公司名稱沒有影響第一次回覆，可以選填。短表單仍可能因名稱不清楚而難填，應以能否完成任務驗收。

電話和 Email 可以都要求必填嗎？

可以有這種業務需求，但應說明為何兩者都必要，以及會用哪種方式聯絡。若任一管道就足以處理詢問，可考慮讓訪客選擇。設定前先確認誰會使用電話、何時會致電；不要只因後台有欄位就要求填寫，也不要在畫面標選填、伺服器卻要求必填。

顯示成功但沒有收到通知信，要請客戶重填嗎？

先查受理紀錄與寄信狀態。若資料已保存，應由內部處理通知問題，通常無須客戶重填。若無法確認是否收件，就如實說明並使用可用的聯絡或查詢管道。網站應預先規劃這種情境，避免每次收不到信都清空表單重送，增加重複與遺漏的可能。

把表單需求交付成可驗收的清單

準備修改網站時，可以交付四份資料：欄位與必填理由、標籤及提示文案、各種送出狀態的訊息、收件與測試紀錄。每份都指定能確認的人：業務確認受理需要，內容窗口確認文字，開發者確認驗證與狀態，實際收件者確認後續處理。

先修正會阻止合理提交、遺失內容或誤報成功的問題，再調整欄位與排版。若需要把這些需求放進整體官網專案，可對照品牌網站建置服務的工作範圍，列出現有表單網址與能重現的情況。具體的交接資料，才能讓設計與開發團隊知道要改善哪一步，以及怎樣才算完成。