How to design and test forms people finish

Forms grow the way loft spaces fill up. Marketing wants to know how people heard about you, sales wants a phone number, finance wants a company name for invoices, and someone once asked for a fax number and nobody took it out. Each field made sense to the person who asked for it. The person filling it in sees all of them at once, on a phone, and has to decide whether the thing on the other side is worth it.

The GOV.UK Design System puts the principle plainly. Know why you’re asking each question, ask only for information you need, and make the reason clear to the user. It recommends running every field through a question protocol, which is a short list of who needs the answer and what they’ll do with it. It costs a meeting rather than a build, which makes it the cheapest friction fix most teams have.

What usually goes wrong

Field count is the obvious one. Baymard Institute’s checkout research found the average US checkout shows 23.48 form elements by default, around 15 of them form fields, while its testing suggests a good checkout can work with 12 to 14 elements, seven or eight of them fields. Checkout is a special case, but the pattern holds for lead forms and sign-ups too. Most forms carry fields that exist for internal convenience.

Labels go wrong next. Placeholder text inside the field, used instead of a label above it, disappears the moment someone starts typing. Nielsen Norman Group’s research found this strains memory, makes it hard to check answers before submitting, and causes trouble for people using screen readers or with low vision, since light grey placeholder text often has poor contrast. Keep a visible label outside the field, and use hint text for anything extra.

Optional and required fields are often marked badly, usually with an asterisk and a legend nobody reads. GOV.UK’s guidance is to avoid asterisks and add “(optional)” to the label of any field that is optional. If a form is mostly optional fields, that’s a sign most of them shouldn’t be there.

Error messages are where forms lose people who were trying. “This field is required” or “Invalid input” in red at the top of the page tells nobody what to do. GOV.UK recommends saying what happened and how to fix it, in plain language, reusing the words of the question, for example “Enter how many hours you work a week”. It also advises keeping everything the user typed, including the valid answers, so they only fix what’s wrong.

Inline validation, and where the experts disagree

Inline validation checks a field as the user goes, rather than waiting for them to submit. Baymard’s 2024 study found 31% of the ecommerce sites it benchmarked had no inline validation at all, and recommends it, with conditions. Don’t flag an error before the person has had a chance to finish typing. Check the field when they leave it, or when a fixed-length entry such as a postcode or card number is complete. Remove the error as soon as it’s corrected. Show a tick when a field is valid.

GOV.UK takes a more cautious line. Its default is to validate when the user submits, and it advises against validating when someone moves away from a field, because it can cause problems for people who type more slowly. Both positions come from user research, with different audiences. A government service has to work for everyone, including people with low digital confidence and assistive technology users. A retailer’s checkout has a narrower audience and a lot of repeat customers. That disagreement is a good reason to test inline validation on your own form, and to include keyboard and screen reader users in the usability testing before you do.

Accessibility is part of the brief

Several of the Web Content Accessibility Guidelines apply directly to forms. Success criterion 3.3.2, Labels or Instructions, requires labels or instructions wherever content needs user input. 3.3.1, Error Identification, requires that when an error is detected automatically, the field in error is identified and the error described in text, so colour alone won’t do. 1.3.5, Identify Input Purpose, at level AA, means fields asking for the user’s own details should declare their purpose in code, usually with the HTML autocomplete attribute, which also lets browsers fill them in. 3.3.7, Redundant Entry, new in WCAG 2.2, means you shouldn’t make people type the same information twice in one process when you could fill it in or let them select it. These are the minimum. They also tend to make forms easier for everyone.

Where to look for evidence

Most analytics setups only record whether a form was submitted. Ask for field-level tracking, which fields people reach, which they leave empty, which produce errors and where they abandon. GOV.UK suggests tracking how often users see each error, and that’s a good place to start, because a single field that errors on a fifth of attempts is usually a label or format problem with a cheap fix. Session recordings and usability tests will show people hesitating over a field, deleting and retyping a phone number because of its format, or scrolling back up to find an error message they missed.

What is worth testing, and how to read it

Removing fields nobody uses is the obvious first test. Moving a field to later in the relationship is another, asking for the phone number after the quote rather than before it. Rewriting error messages and labels is cheap, though small wording changes need a lot of traffic to show up in a test, so be ready to ship some of them as plain fixes.

Measure what comes out of the form as well as how many people finish it. A shorter lead form usually produces more submissions, and sometimes worse leads, especially if the removed field was doing some useful qualifying. Agree a guardrail before launch, such as the share of leads sales accept, or quotes that turn into orders, and read it once enough of them have worked through.

The version to refuse

The shadow version uses the form against the person filling it in. A pre-ticked box to sign up for marketing, consent wording phrased as a double negative, or a required phone number on a form that promises a quick download, when the real purpose is a sales call. In the UK, the ICO is clear that pre-ticked boxes don’t count as valid consent. The earlier lesson on friction covers why adding fields to “qualify” leads usually selects for the wrong people.

What to ask whoever builds the test

Ask who uses each field and what happens to the data. Ask whether field-level analytics are in place, so you’ll see which part changed if the result moves. Ask how errors are announced to screen readers and whether the variant passes the WCAG criteria above. Ask what the quality guardrail is, and when it will be read. If someone proposes a multi-step form, ask whether it reduces what people have to do or only spreads the same fields across more pages.

Put it to work

Take one form that matters to your business and write down, for every field, who uses the answer and what they do with it. Mark any field nobody can name a use for, and any field you could ask for later instead.

Your answer

Show the worked example

There is no right answer. Write yours first, then compare.

Sources

1. GOV.UK Design System: Question pages
2. GOV.UK Design System: Error message
3. GOV.UK Design System: Validation
4. Baymard Institute: Usability Testing of Inline Form Validation
5. Baymard Institute: Cart and checkout form field research
6. Nielsen Norman Group: Placeholders in Form Fields Are Harmful
7. ICO: How should we obtain, record and manage consent?
8. W3C: Understanding WCAG 2.2 Success Criterion 3.3.1 Error Identification
9. W3C: Understanding WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions
10. W3C: Understanding WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose
11. W3C: Understanding WCAG 2.2 Success Criterion 3.3.7 Redundant Entry