Designing Forms That More People Can Actually Finish

Make every field understandable

Use a persistent visible label for every control. Placeholder text can offer an example, but it disappears during entry and is often too faint. Group related fields with a clear heading and explain why sensitive information is needed before asking for it.

Match input types and autocomplete tokens to the data. A phone field should open a useful mobile keyboard; an email field should announce its purpose; dates should not require guessing a hidden format.

• Keep labels visible after typing
• Mark required fields consistently in text
• Write examples that match accepted formats
• Do not ask for information you will not use

Validate without trapping people

Validate when it helps, not on every keystroke. On submission, move focus to a useful error summary or the first invalid field, associate the message with the control, and preserve everything the person already entered.

Messages should explain the fix: “Enter an email such as name@example.com” is better than “Invalid input.” Color can support the state, but an icon, text, and programmatic relationship must carry the meaning.

• Use aria-describedby for field guidance and errors
• Keep native keyboard and browser behavior where possible
• Test Tab, Shift+Tab, Enter, and screen-reader announcements
• Never clear the form after a failed network request

Design the waiting and success states

Prevent duplicate submissions while the request is active and change the button label so progress is obvious. If the request fails, offer a retry and an alternative contact path. If it succeeds, confirm what was received and when a response should arrive.

Multi-step forms need a real progress indicator, Back behavior that preserves data, and validation scoped to the current step. Do not use animation to hide where focus moved.