aladicf/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 reference for validation timing, error placement, multi-field dependencies, async validation, and recovery design. Consult the live validation UX reference for blur-vs-real-time timing, reward-early/punish-late behavior, and copy-paste-friendly validation. Consult the error recovery reference for what happens after validation or submission fails. Consult the disabled buttons UX reference when deciding whether to block submit buttons or keep them enabled with error explanation. Consult the component anatomy 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