Designing forms people actually finish: a practical checklist

A form people finish is short, honest about what it asks for, and forgiving when someone gets something wrong. Most abandonment traces back to a handful of fixable causes: fields nobody reads, labels that vanish the moment you type, errors that arrive too late to help, and a phone keyboard fighting the input. You can audit a form and fix the worst of it in an afternoon.

Start by deleting fields

Field count is usually the biggest lever, and it is the one most teams refuse to pull because every field has a sponsor somewhere in the organisation. The fix is a short, blunt audit that forces the question into the open.

Take the current form and work through it in order:

1. List every field, then name the person who reads the answer and the decision it changes.
2. Delete any field where nobody can name both. Company size, job title and "how did you hear about us" usually die here.
3. Move anything you genuinely need but do not need yet into the follow-up email or the first call. A quote request needs enough to reply intelligently, not a full brief.
4. Derive what you can. City and province from the postal code, page and campaign context from hidden fields you populate yourself rather than questions you ask.
5. Mark what remains as required or optional, and label the optional ones. If most of a form is optional, it is really a shorter form with extras.

One caution: fewer fields raise volume, and volume is not the goal if the extra enquiries are unqualified. If your sales team is drowning, the answer is usually one well-chosen qualifying question in plain language, not five demographic dropdowns.

Labels and error states people can act on

Put the label above the input, in normal-size text, and leave it there. Placeholder-only labels look tidy in a mockup and fail in use: the label disappears the instant someone types, which breaks review, breaks correction, and breaks anyone using translation or magnification. Use the placeholder for a format hint or not at all.

Validation timing matters more than validation logic. Validating on every keystroke shows an error before the person has finished the first attempt, which reads as being told off mid-sentence. Validate when the field loses focus, then re-validate as they correct it so the error clears the moment it is genuinely fixed. Avoid validating only on submit if you can help it, and never clear the form on a failed submit.

Error text should name the field, say what is wrong, and say what will work. "Enter a phone number we can reach you on, digits only" beats "Invalid input." Put the message directly under the field, not only in a summary at the top of the page, and use something other than colour alone to mark it: an icon, a border weight change, and the text itself.

Be liberal about what you accept. Strip spaces from card and phone numbers instead of rejecting them. Accept postal codes with or without the space. Accept a pasted email with a trailing space. Every format rule you enforce that a machine could have handled is friction you chose.

Get the mobile keyboard and autofill right

Plenty of people will meet your form on a phone, and the phone gives you two free wins that cost a few attributes. The right inputmode shows the right keyboard, and a correct autocomplete value lets the browser or password manager fill the field in one tap. Getting these wrong is one of the most common technical defects we find in a form review.

Field	type	inputmode	autocomplete
Full name	text	text	name
Email	email	email	email
Phone	tel	tel	tel
Postal code	text	text	postal-code
Card number	text	numeric	cc-number
One-time code	text	numeric	one-time-code

A few related details. Avoid a numeric input type for anything that is not a quantity, because it strips leading zeros and adds spinner arrows nobody wants on a postal code. Give tap targets room: WCAG 2.2 AA asks for a target of at least 24 by 24 CSS pixels, and anything people tap in a hurry should be comfortably larger. Keep the label and input in one tappable group, and test with the on-screen keyboard actually open: that is when the submit button gets pushed under the fold and the sticky footer covers the field being typed into.

Single page, multi-step, and where the trust signals go

Multi-step is not automatically better. It helps when a form is genuinely long and the questions group into topics a person recognises, because each screen looks manageable and you can save progress between steps. It hurts on short forms, where it turns one scroll into three page loads and hides how much is left.

The rule we use: under about six fields, one page. Longer than that, split by subject rather than by count, show a step indicator that names the steps, and let people go back without losing what they typed. If you split, put the easiest step first and never make step one a question people need to look something up to answer.

A progress bar does not make a long form shorter. It only makes an honest form feel finite.

Trust signals work when they sit next to the hesitation, not in the page footer. Beside an email field, a single line about what you will and will not send. Beside a phone field, when you will call. Beside the submit button, what happens next and how fast. A plain promise about your reply time, placed at the moment of commitment, does more than a wall of badges at the bottom of the page.

Stop spam without punishing people

CAPTCHAs tax the wrong people. Legitimate users on older devices, screen reader users, and anyone on a slow connection pay the cost, while determined bot operators route around them. Treat a visible challenge as the last defence, not the first.

Layer the quiet measures first. A honeypot field, hidden from sighted users and marked so assistive technology skips it, catches naive form-fillers. A minimum time-to-submit check filters scripts that post instantly. Rate limiting by IP address, applied per endpoint, blocks volume attacks. Signed, expiring tokens stop replays. Reject on the server, always, since anything enforced only in the browser is decoration.

If you still need a challenge after all that, use an invisible or risk-scored one that only escalates for suspicious sessions, and make sure there is a working path for people who fail it. A phone number and an email address near the form are not a fallback anyone should have to use, but they should exist. This is also where privacy law lands: if you are collecting personal information from Canadian residents, your handling, retention and consent language belong in the same conversation as your security and compliance review, not bolted on afterwards.

Accessibility that also fixes conversion

Nearly every accessibility fix on a form is also a usability fix, which makes a form one of the easier places to earn WCAG 2.2 AA in practice. Associate each label with its input so tapping the label focuses the field. Group related inputs in a fieldset with a legend so the question makes sense out of context. Give errors an accessible association with their field and announce them politely rather than interrupting.

Then test with the keyboard alone. Tab through the whole form: focus should be visible at every stop, follow the visual order, never jump into a hidden element, and never get trapped in a date picker or a custom dropdown. Custom components are where this usually breaks, so if your framework's decorated select cannot be operated from the keyboard, use the native one. It is faster to build, it works with autofill, and it works on the first try for someone using voice control.

Measure abandonment field by field

Form-level conversion tells you there is a problem. Field-level data tells you where. The instrumentation is small, and it does not need a new tool:

1. Fire an event when the form first receives focus. This is your denominator, and it is not the same as page views.
2. Fire an event on first interaction with each field, and one when that field is left with a value.
3. Record every validation error with the field name and the rule that failed.
4. Record submit attempts separately from successful submissions, so failed submits do not vanish.
5. Compare the drop between consecutive fields once a week and read the error log for the worst one.

The pattern is usually obvious once you look. A field with a high error rate has a format rule that is too strict. A field where people start typing and stop has an unclear question. A form with plenty of starts and few submit attempts has a submit button people cannot find on a phone. Change one thing, wait for enough traffic to be meaningful, and keep the change only if the completed enquiries went up, not just the starts. If you want the measurement and the testing handled as one loop, that is the job of analytics and CRO rather than a one-off audit.

How OlDevs helps

We have been building forms that carry real business since 2014, from a two-field quote request to multi-step intake for regulated workflows. A form review with us covers field discipline, labels and error states, the mobile keyboard layer, spam handling, WCAG 2.2 AA conformance and the analytics needed to prove the change worked. When the fix is bigger than the form, we rebuild the surrounding page or the whole flow through our web development practice, in English or French, with one accountable team and a working demo every week. You own all the code, designs, accounts and IP at the end of it.

If a form on your site is quietly losing people, send us the URL and tell us what happens after someone submits. We reply to every enquiry within one business day. Request a quote and we will start with the field audit.