form-design
Form Design is a Claude Code skill for creating user-friendly forms that reduce abandonment and errors through systematic layout, labeling, and validation practices. Use it when designing any form interface, from simple single-field inputs to complex multi-step flows, to apply evidence-based principles like single-column layouts, top-aligned labels, appropriate input types matched to data, and inline validation on blur rather than keystroke.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/form-design && cp -r /tmp/form-design/interaction-design/skills/form-design ~/.claude/skills/form-designSKILL.md
# 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 type | Input type | |---|---| | Short text | Text input | | Long text | Textarea (with visible resize) | | One from few options (≤5) | Radio buttons (all visible) | | One from many options (6+) | Select / combobox | | Multiple from few options | Checkboxes | | Date | Date picker or segmented inputs (day/month/year) — never a freeform text field for structured dates | | Phone / card numbers | Formatted text input with masking | | Password | Password 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
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.