forms

Build forms that users complete without confusion, anxiety, or abandonment. The goal is not to collect every possible field; it is to remove every unnecessary obstacle between the user and their goal.

Consult the [form validation patterns](../frontend-design/reference/form-validation-patterns.md) reference for validation timing, error placement, multi-field dependencies, async validation, and recovery design. Consult the [live validation UX](../frontend-design/reference/live-validation-ux.md) reference for blur-vs-real-time timing, reward-early/punish-late behavior, and copy-paste-friendly validation. Consult the [error recovery](../frontend-design/reference/error-recovery.md) reference for what happens after validation or submission fails. Consult the [disabled buttons UX](../frontend-design/reference/disabled-buttons-ux.md) reference when deciding whether to block submit buttons or keep them enabled with error explanation. Consult the [component anatomy](../frontend-design/reference/component-anatomy.md) reference for button, input, checkbox, radio, toggle, dropdown, and textarea anatomy guidance.

MANDATORY PREPARATION

Users start this workflow with /forms. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what goal the user is trying to achieve, which fields are truly required, and what causes abandonment in the current flow.

Assess Form Needs

Understand the form's purpose and context:

1. User goal: What does the user get by completing this form? The clearer the payoff, the higher the completion rate.
2. Field necessity: Every field you add drops completion rates. Challenge each field: is it required now, or can it be collected later?
3. Context of use: Is the user rushed, distracted, on mobile, or in a stressful situation? Stressful contexts need simpler forms.
4. Failure points: Where do users currently drop off? Long forms, unclear labels, and unexpected validation are common culprits.

Form Structure

Field order

• Ask easy questions first to build momentum
• Group related fields visually (name fields together, address fields together)
• Place optional fields at the end or mark them clearly
• Separate billing and shipping only when they are genuinely different

Label design

• Use clear, scannable labels above the input (not inside as placeholder text)
• Sentence case is easier to read than Title Case
• Be specific: "Card number" not "Payment info"
• Helper text should explain format requirements, not repeat the label

Input design

• Match input width to expected content (postal code fields should not be full-width)
• Use the appropriate input type (type="email", type="tel", type="date") for mobile keyboard optimization
• Show formatting hints as the user types (credit card spacing, phone number grouping)
• Autofill-friendly: use standard name and autocomplete attributes

Multi-step forms

Break long forms into steps when:

• There are more than 6-8 fields
• The form covers distinct topics (account info, payment, confirmation)
• Users need to review before final submission

Step design:

• Show progress ("Step 2 of 4") so users know what remains
• Allow navigation back to previous steps
• Preserve entered data if the user leaves and returns
• Validate each step before allowing progression, but do not block navigation backward

Validation Strategy

Timing

• Validate on blur for clearly completed fields (email, phone, format-required fields)
• Validate on input only for immediate feedback that helps (password strength, character count)
• Validate on submit for everything else, especially cross-field dependencies
• Never validate a pristine field; it creates anxiety

Error design

• Place error messages directly below the field
• Explain what went wrong and how to fix it
• Use aria-invalid and aria-describedby for screen reader association
• Preserve all user input when validation fails
• Move focus to the first error after failed submission

Success states

• Subtly confirm valid fields with a checkmark or green border
• Remove success indicators when the user edits the field again
• Do not celebrate every valid field; it becomes noise

Mobile Form UX

• Ensure touch targets are at least 44×44px
• Use appropriate input types for optimized keyboards
• Minimize scrolling by breaking into steps or using progressive disclosure
• Show the numeric keyboard for number fields, email keyboard for email fields
• Avoid dropdowns for short lists; use radio buttons or segmented controls instead

Accessibility

• Associate every input with a label using for/id
• Use fieldset and legend for grouped fields
• Announce form-level errors with role="alert" or aria-live="polite"
• Ensure error messages are programmatically associated with fields
• Test keyboard navigation through the entire form
• Do not rely on color alone for error indication

Anti-Patterns

• Too many fields: Every additional field reduces completion rates
• Placeholder as label: Disappears when the user types; bad for memory and accessibility
• Validate on load: Pristine fields showing errors feel accusatory
• Vague errors: "Invalid input" without explanation leaves users guessing
• Clearing fields on error: Losing typed data is deeply frustrating
• Disabled submit without guidance: A grayed-out button with no visible errors is a dead end
• Multi-step without progress indicator: Users do not know how much remains
• Inconsistent validation timing: Some on blur, some on submit, with no clear logic
• Ignoring mobile keyboards: Using type="text" for phone numbers forces users to switch keyboards
• No save-and-resume: Long forms that cannot be saved mid-progress punish interruptions

Verify Form Quality

Before shipping:

• Every field is justified; optional fields are clearly marked
• Labels are clear, specific, and above the input
• Validation does not trigger on pristine fields
• Errors explain what went wrong and how to fix it
• Input is preserved when validation fails
• Focus moves to the first error after failed submission
• Multi-step forms show progress and allow backward navigation
• Mobile keyboards are optimized per field type
• The form is fully keyboard-navigable
• Color is not the only indicator of error or success