Forms that don't lose people

In one sentence

Most form abandonment is caused by decisions you make in the first ten minutes of designing it — label placement, when validation fires, and what happens after an error — not by the number of fields.

Why it matters

Forms are where products collect the thing they exist to collect: the signup, the checkout, the application, the support request. They are also the surface where users are most likely to give up, because unlike browsing, a form has a pass/fail outcome and the failure is theirs.

"Reduce the number of fields" is the advice everyone has heard, and it is real but limited. Removing a field helps once. Fixing validation timing helps on every field, forever. The mechanics of how the form responds while it is being filled in determine whether someone finishes it far more than its length does.

How it works

Labels go above the field. Top-aligned labels are read fastest, survive translation and text expansion, and leave room for an error message that does not reflow the layout. Left-aligned labels are slower to scan and waste horizontal space. Placeholder-as-label is the worst option available: the label disappears exactly when the user needs it, it fails accessibility outright, and it makes a filled field indistinguishable from an empty one at a glance.

Validate on blur, not on keystroke. Validating while someone types means telling them their email is invalid when they have entered t. The pattern that works:

• First pass: validate on blur, once the field has been left.
• After a field has errored: re-validate on input, so the error clears as soon as it is fixed rather than making them leave the field again.
• On submit: validate everything, then move focus to the first error.

That last step is the one most often skipped, and it is the one that matters most on a long form — a user who submits and sees nothing change assumes the button is broken.

Errors say what to do. "Invalid input" is not a message, it is a status code. Name the field, say what is wrong, and say what would be right:

Card number must be 16 digits. You entered 15.

Put the message next to the field, not only in a summary at the top — or do both, but never only the summary.

In practice

The decisions you actually face:

One column. Multi-column forms create ambiguity about reading order and are consistently completed more slowly. The exception is genuinely paired data: city and postcode, expiry and CVC, first and last name.

Mark the optional fields, not the required ones. If most fields are required, asterisks become visual noise on every row. Marking the minority is less ink and more information.

Match the input to the data. Correct inputmode and autocomplete attributes on a mobile form are worth more than any amount of visual design — they change the keyboard and let the browser fill the field. This is the single highest-leverage change on most checkout flows.

Never disable the submit button. A disabled button that gives no reason is a dead end: the user cannot trigger the validation that would tell them what is wrong. Let them submit and show them the errors.

Preserve everything on failure. If a submission fails server-side and comes back with fields cleared, a meaningful share of users will not fill it in again. That is a correctness bug, not a polish item.

Common pitfalls

• Inline validation that fires on every keystroke, so the form spends most of its life telling the user they are wrong.
• Errors rendered above the fold in a summary while the offending field is three screens down, with no link between them.
• Custom select and date components that look right and cannot be operated by keyboard. The native controls are unglamorous and they work.
• Placeholder text used to carry format requirements — it vanishes on focus, precisely when it is needed.
• Progress indicators on a multi-step form that indicate step count rather than progress. Six of nine steps is not two-thirds done if steps four through nine are one field each; say so.

Further reading

The GOV.UK Design System publishes the research behind each of its form components, including the variants that failed — it is the most useful public record of what actually tests well. The WAI ARIA Authoring Practices cover the keyboard and announcement behaviour any custom input has to reproduce.