表單設計指南：減少欄位、寫好錯誤提示，提高詢價表單填寫率

訪客看完服務介紹、決定詢價，點進聯絡頁，卻看到一張要填 15 個欄位的表單：公司統編、預算區間、從何得知本公司、希望聯絡時段……很多人就在這一步放棄了。表單設計是整條轉換路徑的最後一關，前面的廣告、內容、按鈕都做得再好，只要表單讓人卻步，名單一樣進不來。

這篇文章整理 Nielsen Norman Group（NN/g）、Baymard Institute 與 W3C 的研究與指引，說明一張好填的表單該怎麼規劃欄位、標籤怎麼放、錯誤怎麼提示，並結合台灣企業常見的詢價、預約、報名表單情境，給你可以直接檢查的清單。

表單好不好填，差距比你想像的大

NN/g 在〈Website Forms Usability: Top 10 Recommendations〉中引用一項研究：符合可用性準則的表單，有 78% 的使用者能一次就無錯誤送出；違反準則的表單，這個比例只有 42%。 同樣的任務，只因為表單設計不同，一次就順利送出的比例就差了將近一倍。

電商結帳也是同樣的道理。Baymard Institute 長期研究結帳流程，發現 2024 年受測網站的結帳平均有 11.3 個表單欄位，但他們認為多數網站整個結帳流程其實只需要 8 個欄位。Baymard 的調查也指出，有 17% 的使用者曾因為結帳過程太複雜而放棄購買。

第一步：刪欄位，比美化更有效

NN/g 列出的第一條建議就是讓表單保持精簡：可以從其他地方推得的資料、之後再問也來得及的資料、根本用不到的資料，都應該刪掉。

替每個欄位問三個問題：

1. 業務第一次聯絡時，真的需要這個資訊嗎？ 「公司統編」「預算區間」通常可以在電話中再問。
2. 可以自動取得嗎？ 例如由郵遞區號判斷縣市、由登入資訊帶入姓名。
3. 不填會怎樣？ 如果答案是「沒差」，就刪掉或改成選填。

假設一家台北的系統櫃公司，原本的預約表單有 12 個欄位，調整後可以只留：

坪數、預算、屋齡、希望丈量時間，都可以在第一通電話或 LINE 對話中補齊。表單短了，願意送出的人通常會變多，業務接觸到的潛在客戶也有機會跟著增加。

長表單怎麼辦？拆成步驟

有些情境確實需要比較多資料，例如保險試算、課程報名。這時可以把表單拆成幾個步驟，先問簡單、不敏感的問題，最後才問聯絡方式，並顯示進度（例如「步驟 2／3」）。Unbounce 的到達頁建議中也提到，多步驟表單、從簡單問題開始、用選項取代手動輸入，都有助於名單蒐集。

版面：單欄、由上而下

NN/g 建議表單採用單欄排版，每列只放一個欄位，讓使用者的視線一路往下移動。兩欄式排版會讓眼睛左右來回跳，也容易漏填右邊的欄位。例外是幾個邏輯上緊密相關的短欄位，例如「縣市＋鄉鎮區」可以並排。

欄位的順序要符合一般人的習慣：姓名 → 電話 → Email → 地址；信用卡則是卡號 → 有效期限 → 安全碼。NN/g 也提醒，要用鍵盤 Tab 鍵實際測試一次，確認跳格順序和畫面順序一致。

標籤：永遠看得到，不要只靠欄位內的提示字

很多網站為了版面簡潔，把欄位名稱直接寫在輸入框裡（placeholder），使用者一開始打字，提示就消失了。NN/g 有一篇文章直接以〈Placeholders in Form Fields Are Harmful〉為題，列出這種做法的問題：

• 要靠記憶：打到一半忘了這格要填什麼，只能把內容刪掉才看得到提示。
• 很難檢查：送出前想核對，畫面上只剩一堆填好的值，沒有標籤。
• 被誤認為已填：灰色提示字看起來像預設值，使用者以為不用填而跳過。
• 無障礙問題：提示字通常是淺灰色，對比不足；部分螢幕閱讀器也不會念出它。

正確做法是把標籤放在欄位上方，提示文字（例如「格式：0912-345-678」）放在標籤下方或欄位下方，讓它一直可見。W3C WAI 的表單教學也指出，標籤放在欄位上方能減少低視能與手機使用者的橫向捲動，而且每個欄位都必須在程式碼中以 label 元素正確關聯，螢幕閱讀器才知道這格是什麼。

必填、選填與格式要求，事先說清楚

NN/g 建議清楚區分必填與選填欄位，並儘量減少選填欄位。台灣表單常見的做法是在必填欄位加紅色星號，記得在表單開頭說明星號的意思。若表單大多是必填，只標示少數「選填」反而更清楚。

格式要求也要在使用者輸入之前就告訴他，而不是送出失敗後才出現。更好的做法是讓系統接受多種格式：手機號碼不管使用者輸入「0912345678」「0912-345-678」還是「0912 345 678」，都由程式自動整理，而不是要求使用者照你的格式打。

用對輸入類型，手機上差很多

在手機上，輸入框的類型決定跳出哪種鍵盤：

• 電話欄位用電話類型，跳出數字鍵盤
• Email 欄位用 Email 類型，鍵盤上直接有「@」
• 加上正確的 autocomplete 屬性（如 name、tel、email、postal-code），瀏覽器就能自動帶入資料。web.dev 的表單教學也建議電話、信用卡號使用單一輸入框，才能支援自動填入

選項只有兩三個時，NN/g 建議用單選按鈕取代下拉選單，一次點擊就完成，不用先展開再選。手機版的完整注意事項，可參考行動優先與 RWD 響應式設計。

即時驗證與錯誤訊息

驗證時機：不要太早罵人

Baymard 的測試發現，在使用者還沒打完就跳出錯誤（例如 Email 才打兩個字就說「格式錯誤」），會讓人很煩躁，甚至懷疑自己原本正確的輸入。有受測者形容「感覺它在對我大吼」。Baymard 建議：

• 在使用者離開欄位時才檢查；郵遞區號、手機號碼這類固定長度的欄位，可以在長度達到時檢查。
• 錯誤一修正就立刻消失，不要等使用者離開欄位。
• 填對時給予正面回饋，例如在欄位旁顯示勾勾。

Baymard 也提醒，即時驗證不能取代送出時的檢查，兩者都要做。

錯誤訊息要具體、要顯眼

NN/g 對錯誤訊息的建議是：

• 用多種提示呈現錯誤，不要只靠紅色。框線加粗、錯誤文字、圖示一起使用，色弱使用者才看得出來。
• 保留使用者已輸入的內容，絕對不要送出失敗後整張表單清空。
• 說清楚哪裡錯、怎麼改：「請輸入 10 碼手機號碼，例如 0912345678」比「格式錯誤」有用得多。

錯誤訊息寫在出錯的欄位旁邊；若錯誤不只一個，在表單頂端放一個摘要，並把畫面帶到第一個錯誤欄位。

送出按鈕與送出之後

• 按鈕文字說清楚結果：「送出預約」「取得報價」比「送出」好。
• 不要放「清除」或「重設」按鈕：NN/g 指出誤按會讓辛苦填的資料全部消失，而真正需要重來的情況很少。
• 不要用停用按鈕卡住使用者：讓按鈕保持可按，送出時再指出問題。按鈕設計細節請見 CTA 按鈕設計指南。
• 送出後給明確的確認：告訴使用者「我們會在一個工作天內以電話聯絡您」，並提供 LINE 等其他聯絡方式。這個感謝頁也是設定轉換追蹤的位置。

個資告知：台灣表單不能省的一段

依台灣個人資料保護法，蒐集個資時應告知蒐集目的、資料類別、利用期間與方式等事項。實務上，可以在送出按鈕附近放一行簡短說明並連結到完整的隱私權政策。若要把名單用於行銷，例如寄送電子報、加入再行銷名單，最好另外提供勾選讓使用者同意，而不是預設打勾。清楚的告知不只是合規，也是一種信任訊號。

表單設計檢查清單

• 每個欄位都是現在就必須問的嗎？
• 是否採用單欄、由上而下的排版？
• 標籤是否在欄位上方、一直可見，而不是只用欄位內提示字？
• 必填與選填是否標示清楚？
• 電話、Email 欄位在手機上會跳出正確的鍵盤嗎？
• 是否設定了 autocomplete 讓瀏覽器自動帶入？
• 錯誤是否在離開欄位時才檢查、修正後立即消失？
• 錯誤訊息是否具體，並保留使用者已輸入的內容？
• 送出後是否有明確的確認訊息？
• 是否有個資告知與隱私權政策連結？

常見問題

詢價表單最多放幾個欄位？

沒有固定上限，原則是只問第一次聯絡必需的資訊。多數服務業的詢價表單，保留稱呼、電話、需求地區與需求簡述就足夠，其他資料可以在後續溝通中補齊。

欄位內的提示文字完全不能用嗎？

可以用來放範例，但不能取代標籤。NN/g 指出提示字在輸入後會消失、對比通常不足，部分螢幕閱讀器也不會念出。欄位名稱一定要用永遠可見的標籤呈現。

需要加驗證碼防止垃圾訊息嗎？

垃圾訊息確實需要處理，但要求辨識扭曲文字的驗證碼會增加使用者負擔，也有無障礙問題。可以優先考慮伺服器端過濾、隱藏欄位等對使用者無感的方式，真的需要時再選擇較不干擾的驗證機制。

用 Google 表單當官網詢價表單可以嗎？

小規模可以，但它會讓使用者離開你的網站、外觀難以統一，轉換追蹤也較難設定。若表單是主要名單來源，建議直接做在官網上，並串接通知與 CRM。

結語：每刪掉一個欄位，就少一個放棄的理由

表單設計的核心是同理：使用者是在幫你一個忙，把資料交給一家他還不太認識的公司。只問必要的問題、讓標籤一直看得見、錯誤提示說人話，這些看似細小的調整，累積起來就是填寫率的明顯差異。表單也要讓使用輔助科技的人填得了，可以延伸閱讀網站無障礙設計（WCAG 2.2）。

網軍行銷的名單型網站規劃會一併檢查表單、追蹤與後續通知流程，讓名單從送出到業務聯繫不漏接。想把表單放進完整的轉換頁面，可以接著看到達頁設計與轉換率，或回到企業官網設計完整指南。

參考資料

• Nielsen Norman Group，Website Forms Usability: Top 10 Recommendations：https://www.nngroup.com/articles/web-form-design/
• Nielsen Norman Group，Placeholders in Form Fields Are Harmful：https://www.nngroup.com/articles/form-design-placeholders/
• Baymard Institute，Usability Testing of Inline Form Validation：https://baymard.com/blog/inline-form-validation
• Baymard Institute，Checkout Optimization: Minimize Form Fields：https://baymard.com/blog/checkout-flow-average-form-fields
• W3C WAI，Labeling Controls（Forms Tutorial）：https://www.w3.org/WAI/tutorials/forms/labels/
• web.dev，Learn Forms: Autofill：https://web.dev/learn/forms/autofill