The Forms Canon: Every Field Is a Question

A form is the moment an interface stops presenting and starts asking. Every field is a question put to a person who wants to be doing something else, which means every unnecessary field is an imposition and every confusing one is a small betrayal. The craft of forms reduces to a canon you can hold in your head: ask fewer questions, in one column, with visible labels; accept answers the way people naturally give them; fire validation when the user finishes a thought, not mid-keystroke; write errors that say how to fix the problem; and never, under any circumstances, throw away what the user typed. Most form friction in the wild is a violation of one of those lines.

TL;DR

• A form is a conversation, so ask like a person would: fewest possible questions, in one ordered column, grouped by topic – and justify every field against the cost of asking it.
• Layout is settled: single column, labels above the field, field width hinting at answer length. Multi-column forms and floating-label tricks trade real comprehension for imagined polish.
• Accept answers the way people give them. Trim the stray space, take the phone number in any format, keep the field whole instead of splitting it into three boxes – normalization is the software’s job, not the user’s.
• Validate on blur, not on keystroke, and write errors that teach: what went wrong, how to fix it, next to the field it concerns.
• The user’s input is sacred. A failed submit that clears the form, or a disabled button that won’t say why, converts a willing participant into a former one.

Why Every Field Is a Question

Treat a form as a transcript of an interview and its quality becomes legible. Would a competent interviewer ask for your fax number out of habit? Demand your date of birth before explaining why? Interrupt you halfway through spelling your email to announce it is invalid? Forget everything you said because your postcode had a space in it? Every one of those has a shipping-form equivalent, and users experience them the way they would experience the interviewer: as rudeness.

The framing also produces the first and most important rule, the one that precedes all layout and styling: every field must justify its existence against the cost of asking. Each additional question raises abandonment; each collected answer is data you now store, secure, and answer for. The strongest form design move is deletion – the field you remove outperforms any polish you could apply to it. The canonical receipt is Expedia’s: deleting a single optional field, “Company,” from the booking form was reportedly worth about $12 million a year – customers had been entering their bank’s name there, then failing address verification. One field, honestly interrogated, beat any redesign. “Optional” is not a justification; it is a smaller imposition, still an imposition. Ask what you need to complete the transaction, mark the rare optional field as optional, and move everything else to later, when the relationship has earned it. (The opposing camp asterisks every required field instead; when nearly everything is required, the asterisks are wallpaper.)

The Layout Rules

Form layout is one of the few corners of design where the evidence is essentially settled, which makes deviation a choice against the user:

One column. A form is a sequence of questions, and a single column makes the sequence unambiguous: answer, move down, finish. Multi-column layouts force a reading-order decision on every row – across or down? – and users resolve it inconsistently, skipping fields they never saw. In the best-known eyetracking comparison, the same fields in a single column finished roughly fifteen seconds faster than split across two. The exceptions are genuine composites that read as one answer: city / state / zip on a line, a date as three parts. Those are one question wearing three inputs, not three questions.

Labels above the field, always visible. Labels beside fields create ragged eye travel; labels inside fields (placeholder-as-label) vanish the moment the user starts typing, which is precisely when they need them – halfway through a long form, every filled field becomes a mystery box of what-was-this-again. Floating labels, the animated compromise, survive focus but shrink to caption size and make empty fields read as filled: a gentler version of the same trade, still paid in comprehension. Placeholders are for format hints (“you@example.com”), never for the question itself.

Field width is information. A zip code field as wide as an address field lies about the answer’s shape. Sizing inputs to their expected content – short for postal codes, long for addresses – is the same craft as spacing that encodes grouping: geometry doing quiet communication.

Group by topic, and let space do the grouping. Contact, shipping, payment – clusters of related questions with clear seams between them, the seams made of whitespace rather than boxes or rules. A form that reads as three small topics is psychologically smaller than the same fields as one undifferentiated slab.

The Input Rules

The theme of input design is a single sentence: normalization is the software’s job. Whatever formatting burden exists, the machine carries it, because the machine is the one that cares.

• Accept sloppy answers. Trim whitespace – the trailing space from an autocompleted email has failed more logins than it has any right to. Take phone numbers with dashes, dots, spaces, parentheses, or nothing. Accept the card number with or without gaps. If you can parse it, parse it; rejecting 555 867 5309 because you wanted 5558675309 is making the user run your string-formatting code by hand.
• Never split what the user thinks of as one thing. Phone numbers in three boxes, dates in three dropdowns, verification codes in six single-character cells with hand-rolled focus-jumping – each splits one mental answer into a navigation puzzle and usually breaks paste, the most efficient input method the user owns. (The layout rules’ composite exception survives: a date as three typed parts is fine – the sin is the dropdown ceremony and the stolen focus, not adjacency. And for codes, the durable answer is one input with autocomplete="one-time-code".)
• Summon the right keyboard. On touch devices, type="email", inputmode="numeric", and friends are the difference between typing an address on a keyboard designed for it and hunting for @ through symbol layers. This costs one attribute.
• Let the browser help. Correct autocomplete tokens turn a twelve-field checkout into two taps for a returning user. Disabling autofill on address and payment fields – usually superstition inherited from a security review that never happened – discards the largest single speedup available to a form.
• Meet the finger where it lands. Fields, their buttons, and anything else tappable hold the platform’s minimum touch target – 44pt on iOS, 48dp on Android. A compact, elegant field the thumb cannot reliably hit is a desktop form wearing a phone costume.

The keyboard and autofill rules together cost a few attributes:

The Validation Rules

Validation timing is where forms are most often hostile, and the rule is simple: respond when the user finishes a thought. Firing on every keystroke means yelling “invalid email!” at someone four characters into typing one – criticizing sentences before they end. The opposite school validates only on submit, and it has a serious defender: GOV.UK’s design system does exactly this, pairing submission with an error summary at the top of the page, because a summary is announceable to screen readers and gives keyboard users one place to start repairs. That is a coherent position, tuned for services where accessibility is the binding constraint. For most product forms I hold the blur position anyway: the user completes the field, moves on, and gets feedback at the seam between thoughts, while the thought is still warm. (One refinement: a field that was invalid may re-validate on keystroke, so the red state clears the instant the fix lands rather than lagging a full field behind.)

Error writing follows the same conversational test. An error is not a verdict; it is a repair instruction. “Invalid input” fails the test – invalid how? “This email address is missing its @” passes. (And the instruction must be true of the actual rule: card numbers legitimately run 12 to 19 digits, so “must be 16 digits” is not an error message, it is a validation bug that rejects every Amex holder.) Place the message at the field it concerns, in text – color alone excludes colorblind users, and text is the only channel a reader that renders nothing can see – and bind it to its input programmatically (aria-describedby), so assistive tech announces the error with the field instead of leaving it stranded on screen. Keep the tone factual: the form’s job is to get the user through, not to adjudicate fault. The whole rule in one pair:

Email

Invalid input


Email

This email address is missing its @

Two structural rules complete the set. Never disable the submit button as a validation strategy – a dead button with no explanation is a puzzle, and the user’s next move is leaving; let them submit, then show precisely what needs attention. (Disabling during an in-flight submission to prevent a double charge is different: that is state, not judgment.) And the deepest law of the canon: a failed submit preserves every keystroke of the user’s work. A form that clears on error has taken minutes of a person’s effort and burned it in front of them. No visual refinement recovers from that.

The Canon as Checklist

The working form of all of the above, applied to any form before it ships:

In a design system, these harden into the form components themselves – a text field that ships with its label slot above, its error slot below, its validation timing built in – so the canon holds by default and drift requires effort. That is the same systemization argument as motion tokens: encode the decision once, or relitigate it in every feature.

FAQ

Should a form use one column or two?

One column. A single column makes answer order unambiguous and measurably faster to complete; multi-column layouts cause skipped fields because users resolve the reading order inconsistently. The exception is a composite answer – city / state / zip – which is one question expressed as adjacent inputs.

When should form validation fire?

On blur – when the user leaves a field – not on every keystroke, and for most product forms not saved up for submit. Keystroke validation criticizes unfinished answers; submit-only validation delivers every failure at once, though GOV.UK’s on-submit error summary is the right call where screen-reader announcement is the binding constraint. A field already marked invalid may re-check per keystroke so the error clears immediately when fixed.

Is it okay to use placeholder text as a field label?

No. Placeholder-as-label disappears once the user starts typing, exactly when they need to recall the question, and turns every filled field into unlabeled data on review. Keep a visible label above the field and reserve placeholders for format examples.

Should the submit button be disabled until the form is valid?

No. A disabled submit with no explanation is a dead end the user has to diagnose. Keep it enabled, and on submit surface each unresolved field with a specific, instructive error beside it – while preserving everything the user has already entered.