The highest-traffic UI nobody designs: forms

Open your product's analytics and sort screens by sessions. Somewhere near the top — behind the homepage, ahead of almost everything else — sit your forms. Signup, checkout, contact, search, settings, every CRUD screen your users touch daily. Now open your design file and count how many artboards are forms. In most handoffs we audit, the answer is one: the signup page, designed at launch, never touched since.

Forms are the highest-traffic UI nobody designs. They're also where conversion happens or dies, which makes the neglect doubly strange. We've written before about designing forms people actually finish at the strategy level; this is the working-level companion — the specific decisions that separate a form that feels effortless from one that quietly bleeds intent.

Labels are the interface; placeholders are a rumour

The most common form mistake in the wild is still the placeholder-as-label pattern: an empty field with grey text inside it saying "Email address". It looks clean in the mockup. In use it fails four ways at once: the label vanishes the moment you type (now you're guessing what this field was), placeholder contrast almost never meets 4.5:1, screen readers handle it inconsistently, and autofill makes the whole form a wall of identical empty boxes.

Our rule: every field gets a persistent, visible label above the input. Floating labels are acceptable if they animate to a readable size and never disappear; placeholders become examples ("you@company.com") or hints, never identification. This isn't purism — it's the pattern our own contact brief form ships with, built after watching test participants lose track of which field they were editing mid-sentence.

Two details most teams miss. First, label length: keep it to two or three words, and put qualifiers ("optional", or the format you need) in smaller hint text beneath the label, not inside the input. Second, programmatic association: <label for> or wrapping, every time. "It looks associated visually" fails the moment someone navigates by keyboard or screen reader.

Validation timing: the three moments that matter

Inline validation is a solved problem that everyone implements badly. The bad version validates on every keystroke — typing a into the email field immediately triggers a red "invalid email" error, punishing the user for not being finished. The lazy version validates only on submit, dumping ten errors at the end like an accusation. The working version picks moments deliberately:

• On input: never complain. While the user is typing, show nothing negative. You may show positive progress (a checkmark once an email parses) because early positive feedback reduces anxiety; early negative feedback just creates it.
• On blur: validate what they left. When focus leaves a field that has content, validate it then. This is the moment the user has declared "I'm done with this one." Correct them now, while the context is warm.
• On submit: catch everything, then guide. Submit-time validation collects all remaining errors, moves focus to the first one, and summarises at the top for keyboard and screen-reader users. Error summary + per-field messages is redundant in a good way: sighted users scroll, keyboard users get focus order.

One exception that proves the rule: password-strength meters and username-availability checkers should respond while typing, because their entire purpose is live guidance. The principle isn't "never validate on input" — it's "never scold on input."

Error messages are copywriting, not logging

"Invalid input" is a stack trace wearing a trench coat. A good error message has three parts, in order: what happened, why it happened, what to do about it. Compare:

• "Error" → "We couldn't save your card. The expiry date has passed. Use a card expiring after June 2026."
• "Invalid ABN" → "That doesn't look like an ABN. Australian Business Numbers are 11 digits — check for a missing or extra digit."

Notice the voice: we couldn't, you didn't fail. Blame lives with the system. We wrote about the de-escalation psychology in error messages that help; the form-design companion rules are mechanical:

1. Errors appear adjacent to the field, not just in a toast that vanishes.
2. The field keeps its error state until the user has edited it — not after one keystroke, which makes the user chase a moving red box.
3. Error text supplements colour; never replaces it. Red alone fails colour-blind users and every contrast standard.
4. Format expectations go in hint text before the user errors ("DD/MM/YYYY"), not only in the error after.

Single-column dogma, and its honest exceptions

"Always single-column" is good advice that gets recited past its evidence. One column keeps the eye on a single path, and eye-tracking studies consistently show multi-column forms get misread — the classic failure is users skipping the right column entirely. So: single column, default, full stop.

The honest exceptions, earned through testing rather than taste:

• Genuinely paired fields — expiry + CVC, city + postcode, date-from + date-to — can share a row when they're conceptually one answer. One row, not a grid.
• Very short flows (two or three fields) barely benefit from column discipline either way.
• Expert, high-frequency tools — the dispatch console, the trading blotter — trade scannability for density because the same person uses them 400 times a day. If you're designing one of those, see our notes on data tables for people who live in them.

What never works: two-column layouts on marketing signup forms. You are optimising for a design-review screenshot against your own conversion rate.

Autofill is a feature you ship

Users experience autofill as magic when it works and sabotage when it doesn't. The difference is almost entirely autocomplete attributes, and almost no team sets them. Annotate every field with the right token (email, given-name, family-name, postal-code, cc-exp, tel...) and you get browser autofill, password-manager integration, and the correct mobile keyboard for free. It's an afternoon of work with an outsized completion-rate payoff. The engineering side — schema-first forms, machine-readable errors — is covered in our form architecture at scale piece.

Address handling deserves its own paragraph. Don't build five country fields when a post/zip code lookup can fill four of them. Don't force "State" on countries that don't have one. And never alphabetise a country dropdown without pinning the likely choices — making an Australian user scroll past Azerbaijan to find Australia is a small humiliation multiplied across your whole audience.

Mobile keyboards: inputmode="numeric" for card numbers and postcodes, type="email" and type="tel" so the right keys surface, and never type="number" for anything that isn't a quantity — number inputs mangle leading zeros, allow e and +, and are the single most-misused element in forms. Credit card inputs should be plain text fields with numeric input modes and forgiving formatting (accept spaces, strip them, re-group for display).

The checklist

Before any form ships at Brassfern, it passes this list. Print it; argue with it; you'll win more arguments than you lose:

1. Every field has a visible, persistent label — placeholders are hints, never labels.
2. Required fields are the default; optional fields are marked optional, not the reverse.
3. No validation scolding during typing; validate on blur, summarise and refocus on submit.
4. Error messages say what happened, why, and what to do; blame the system, not the user.
5. Single column except genuinely paired fields; tested, not assumed.
6. autocomplete attributes on every field that has a standard token.
7. Numeric input modes without type="number" abuse; keyboards match the data.
8. Format hints before errors, not only in errors.
9. The whole form completable by keyboard alone, with a visible focus state.
10. Submit button states the outcome ("Pay $48", "Send my brief"), never "Submit."

When we rebuilt the intake steps of Pylon Health's telehealth flow against this list, completion on the medical-history section rose from 61% to 88% — illustrative numbers, but the pattern repeats across every form project we touch.

Key takeaways

• Forms are your highest-traffic UI; design them with the same care as your homepage, and audit them yearly.
• Labels persist; placeholders give examples; hint text carries format expectations.
• Validate on blur, not on keystroke; summarise and refocus on submit.
• Error copy answers what/why/what-next and blames the system.
• Single column except conceptually paired fields and expert-density tools.
• autocomplete attributes and correct input modes are the cheapest conversion win on the web.

Frequently asked questions

Should we mark required fields or optional ones?

Mark the minority. On most forms nearly everything is required, so mark the optional ones "(optional)" — it takes less ink and users skim it correctly. If most of your form is optional, ask why those fields exist at all.

Are multi-step forms better than long ones?

Only when steps are meaningful to the user ("About you" / "Your business"), not when they're arbitrary chunks. One long form with clear section headers beats five steps that exist to game a progress bar. Never hide a form's true length.

When should we save progress?

Any form longer than five minutes of work, any form on mobile, any form with payment involved. Silent autosave with a quiet "saved" indicator has rescued more sessions than any redesign we've shipped.

Is it okay to auto-advance between fields (e.g. expiry dates)?

Only in strict fixed-length patterns (expiry MM/YY, segmented OTP inputs), and even then, test it. Auto-advance on anything free-form breaks paste, muscle memory and screen readers. When in doubt, let the user tab.

Do captchas belong on forms?

As a last resort, invisible, and never on logged-in flows. A form behind a captcha is a form asking users to prove they deserve to give you money. Rate-limit and honeypot first; challenge the traffic, not the person.