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.
.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.md
Cursor / Windsurf rule
Project-scoped rule. Loads when editing form components.
save as .cursor/rules/complex-forms.mdc
Download.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
- 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 → - 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 → - 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 → - 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 → - 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
- 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 - 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 - 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 - 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
- 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.