← Resources

patterns / complex form

Designingthe complex form

A working notebook for the field types, cross-cutting concerns, and mobile mechanics that decide whether a long form gets finished.

Most enterprise forms aren't broken because the design is ugly. They're broken because the small mechanical choices — which keyboard appears, when validation fires, whether autofill works — were never made on purpose. These are the notes I keep open when I'm building one.

5 of 10 parts published · updated may 2026

AI-consumable spec

Download the rules. Drop them into your AI.

The same rules and checklists from this series, hand-curated as a dense, prescriptive spec — for Claude Skills, Cursor / Windsurf rules, or any AI assistant. Three formats, same content, different frontmatter.

  1. .md

    Claude Skill

    Drop into ~/.claude/skills/ — auto-loaded by Claude Code and the Agent SDK.

    save as ~/.claude/skills/complex-forms/SKILL.md

    Download
  2. .md

    Cursor / Windsurf rule

    Project-scoped rule. Loads when editing form components.

    save as .cursor/rules/complex-forms.mdc

    Download
  3. .md

    Tool-neutral Markdown

    Paste into any AI — Claude.ai, ChatGPT, Gemini — as context.

    copy / paste into your assistant

    Download

The articles describe the reasoning. The spec describes the rule. Apply the rule.

Field types

  1. 01

    Text inputs — the field type that breaks first

    Single-line, multi-line, email, password, phone. The basics most forms get wrong before they ever get to the interesting parts.

    9 min read · read →
  2. 02

    Selects, dropdowns, and the comboboxes in between

    Native <select>, custom listboxes, multi-select, search-as-you-type. When each one is the right answer — and when it's the wrong one in disguise.

    8 min read · read →
  3. 03

    Checkbox, radio, toggle — and the decision between them

    Three controls, three meanings, picked nearly at random in most products. The semantic differences and the cost of getting them wrong.

    7 min read · read →
  4. 04

    Date and time pickers — the field where native usually wins

    Native <input type="date"> versus custom calendars. The cases where rolling your own is justified, and the cases where you're just making the form slower.

    8 min read · read →
  5. 05

    File upload and autocomplete — the heavy interactions

    Two field types that look simple on a comp and break in ten different ways under real data.

    10 min read · read →

Cross-cutting

  1. 06

    Validation timing and the grammar of error messages

    When to fire. Where the error appears. What it says. Three decisions that fail independently in every form review I've ever run.

    draft
  2. 07

    Accessibility for forms — the parts that aren't optional

    Focus order, ARIA, target sizes, error association, contrast. The checklist that decides whether the form is shippable, not whether it's polished.

    draft
  3. 08

    Autosave and draft recovery — the feature users only notice when it isn't there

    Long forms lose data. The browser crashes, the session expires, the user hits back. Designing the save so they don't notice the loss.

    draft
  4. 09

    Internationalization — names, addresses, phones, dates

    Form fields built for the English-speaking, US-centric assumption fail the moment a real customer outside that assumption uses them.

    draft

Mobile mechanics

  1. 10

    Mobile input mechanics — the small things that decide everything

    inputmode, the 16px floor, keyboard submission, viewport-when-keyboard-opens, native pickers. The mechanical decisions that compound across every field in the form.

    draft

The series is being written one part at a time. Drafts are listed here so the structure is visible — they'll appear in full as they're finished.