Form design and validation: the patterns that lose you conversions

01Validate on blur, re-validate on change

Validating on every keystroke means telling someone their email address is invalid while they are typing the third character of it. The error is technically correct and experientially hostile, and it trains people to ignore the error region entirely, which is expensive when a real error appears.

The pattern that works is validate on blur for the first pass, then once a field has an error, re-validate on change so the error clears the moment it is fixed. That gives the user room to finish their thought and immediate confirmation when they correct something. Format-as-you-type for card numbers and phone numbers is fine and helpful - that is formatting, not validation.

02Error messages that say what to do

"Invalid input" tells the user nothing. "Password must contain a number" tells them what to change. The test is whether someone can act on the message without re-reading the field label or guessing at a rule they were never shown, and most production error copy fails it.

Show the constraints before submission rather than as punishment after. If a password needs twelve characters and a symbol, say so under the field from the start, and mark each requirement as it is met. This turns validation from a gate into a checklist, and it removes an entire class of failed submissions.

03Never disable the submit button

A disabled submit button is the most common well-intentioned mistake in form design. From the user's side it is a dead control with no explanation - something is wrong somewhere, and the interface has removed the one action that would tell them what. On mobile, where the invalid field is often scrolled out of view, it is a dead end.

Keep the button enabled. On submit, validate everything, show all errors at once, move focus to the first one, and scroll it into view. The user gets a complete list rather than discovering problems one at a time, and screen reader users get the error announced rather than silently encountering an inert control.

• Enabled submit, full validation on click, focus the first error.
• Summarise errors at the top with links to each field on long forms.
• Announce errors via a live region so they are not silent to assistive tech.
• Show a busy state on submit and block double submission server-side too.

04Field count and the things you do not need to ask

Every field costs completions, and the cost is not linear - optional fields that look mandatory, fields that require looking something up, and fields whose purpose is unclear cost far more than their share. The largest available win in most forms is deleting fields rather than styling them.

Audit each field against whether the answer changes anything today. Company size collected for a report nobody reads, a second phone number, a title dropdown - each has a real conversion cost. Where you genuinely need the data, ask for it after the commitment rather than before it, and derive what you can: postcode lookup instead of four address lines, card type from the number's prefix instead of a dropdown.

• Mark optional fields explicitly rather than marking required ones.
• Derive rather than ask - address from postcode, card type from BIN.
• Move non-essential questions after the conversion point.
• One column. Multi-column forms cause skipped fields and unpredictable tab order.

05Input types, autofill and the mobile keyboard

On mobile, the wrong input type means the wrong keyboard, and a numeric entry on a full QWERTY layout is measurably slower and more error-prone. Use the appropriate type and inputmode for numeric, email, telephone and URL fields - it is a one-attribute change with a direct effect on completion time.

Autocomplete attributes matter just as much and are routinely omitted or actively broken by custom components. Correct autocomplete tokens let the browser and password manager fill an address or card in a single tap. Blocking paste on password or confirmation fields is worse than useless: it defeats password managers, so it pushes people towards weaker, memorable passwords.

06Long forms: save state and be honest about progress

Anything beyond a screen or two needs persistence. A session timeout, an accidental back navigation or a phone call that backgrounds the browser should not cost twenty minutes of typing. Save to local storage as the user types and restore on return, with a clear indication that it happened.

If you split into steps, group by the user's mental model rather than by your data model - the questions someone can answer without leaving the page belong together. Show real progress rather than a decorative bar, and let people move backwards without losing what they entered ahead. And validate each step as they leave it, so nobody reaches step five and is sent back to step one for a fixable typo.