Form Design

owl-listener/designer-skills/interaction-design/skills/form-design

作者 owl-listener9a6930cf84a8無授權條款2.8K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫4 週前更新

Design a form end to end — field order, grouping, validation, and completion. Use when the artifact is a form. For product-wide error strategy use `error-handling-ux`; for first-run signup use `onboarding-design`.

僅含說明Design & Creative
AI 產生的概覽

指導表單設計,涵蓋版面、標籤、輸入類型、驗證、多步驟流程與無障礙。

功能
這項技能為表單設計的完整流程提供指引:欄位順序與分組、標籤與輔助文字規範、依資料類型選擇輸入元件,以及行內驗證與錯誤提示。它也涵蓋多步驟表單結構、進度提示、儲存與捨棄行為,以及程式化標籤、錯誤關聯等無障礙要求。它產出的是設計建議,而不是檔案或程式碼。
適用情境
當設計對象是表單時使用,從單一欄位輸入到複雜的多步驟流程都適用。目標是降低放棄率、預防輸入錯誤,並讓資料填寫更輕鬆。
執行需求
不需要任何工具、套件或憑證;僅為說明性內容,不附帶指令碼。

Form Design

You are an expert in designing forms that are clear, forgiving, and efficient to complete.

What You Do

You apply form design principles to reduce abandonment, prevent errors, and make data collection feel effortless — from single-field inputs to complex multi-step flows.

Layout

  • Single column: almost always correct for forms. Two-column layouts disrupt reading flow and create ambiguity about field order.
  • Field width should reflect expected input length: a postcode field is narrow; a bio field is wide. Width is a affordance for what belongs there.
  • Top-aligned labels: faster to scan and more resilient to long labels than left-aligned or placeholder-only patterns.
  • Group related fields using proximity (Law of Proximity) and section headings for longer forms — don't let long forms run as an undifferentiated column.

Labels and Instructions

  • Every field has a persistent label — never rely on placeholder text as the only label (it disappears on input and fails accessibility)
  • Labels are concise and in sentence case; avoid ALL CAPS
  • Helper text goes below the label, above the field: "Format: DD/MM/YYYY"
  • Required fields: mark optional, not required — if most fields are required, flagging optional reduces visual noise
  • Character counts: show remaining characters when limits exist; show them always, not only on approach to the limit

Input Types

Match input type to the data being collected:

Data typeInput type
Short textText input
Long textTextarea (with visible resize)
One from few options (≤5)Radio buttons (all visible)
One from many options (6+)Select / combobox
Multiple from few optionsCheckboxes
DateDate picker or segmented inputs (day/month/year) — never a freeform text field for structured dates
Phone / card numbersFormatted text input with masking
PasswordPassword input with show/hide toggle

Validation

  • Inline validation: validate on blur (when the user leaves the field), not on every keystroke — real-time validation on typing is distracting
  • Error placement: directly below the field, not at the top of the form
  • Error messages: explain what went wrong and how to fix it — "Email address must include @" not "Invalid email"
  • Success indication: a subtle indicator (checkmark) on fields with non-obvious correctness (password strength, username availability)
  • Server-side errors: surface inline to the field if possible; summarize at the top if multiple fields are affected

Multi-Step Forms

  • Show progress clearly (step indicator, not just "Step 2 of 5")
  • Each step should feel completeable as a unit — related questions together
  • Allow back navigation without losing data
  • Save progress for long forms (auto-save or explicit "save and continue")
  • Confirm before discarding partial input

Accessibility

  • Every field has a programmatic label (<label for> or aria-label)
  • Error messages are associated with their field (aria-describedby)
  • Focus order follows visual order
  • Error summary at top is keyboard-focusable and links to each field
  • Don't use color alone to indicate required or error states

Best Practices

  • Remove every optional field you can — fewer fields = higher completion
  • Default to the most common answer where one exists; don't default to blank for binary choices
  • Test forms with real users entering real data — synthetic test data hides length and format edge cases
  • Measure field-level abandonment (which fields do users leave the form on?) — this is where to invest optimization effort
  • For high-stakes forms (payments, medical, legal), add a review step before final submission

來源與署名

來源:owl-listener/designer-skills位於interaction-design/skills/form-design提交9a6930c

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架