Designing forms people finish

Forms are where a website asks for something: an enquiry, a booking, a payment, a sign-up. They are also where people give up. Every field is a small cost to the person filling it in, and confusing labels or unhelpful errors add more. The good news is that the fixes are well documented and cheap to apply.

This guide draws on three of the most tested sources available: the GOV.UK Design System, which is built from research on public services used by millions of people; the Nielsen Norman Group’s form guidelines; and Baymard Institute’s checkout research. It covers what to ask, how to label it, and how to handle errors.

Ask for less

The GOV.UK guidance on question pages says to ask only for information you really need, and to know why you are asking each question. NN/g’s top 10 recommendations for website forms gives practical ways to cut: remove fields you can work out from other answers, collect later, or do without.

Baymard’s research on checkout form fields shows how far most sites are from this. It found the average checkout in its 2024 benchmark had 11.3 form fields, while most sites need only eight in total. Typical candidates for removal include a second address line shown by default, a separate “confirm email” field, title (Mr, Mrs, Ms), company name for consumers, and phone number when you never call.

For each field, ask three questions. Do we use this answer? Could we get it another way? Could we ask for it later, once the person is already a customer?

Labels people can see and understand

The GOV.UK text input guidance is firm: all text inputs must have labels, and in most cases the label should be visible. Put labels above the field, keep them short, and drop the trailing colon. NN/g also recommends labels directly above fields, and warns against spacing that leaves a label equally close to two fields.

Placeholder text (the grey text inside an empty box) is not a label. Both sources advise against using it. GOV.UK’s reasons: it disappears as soon as someone starts typing, and browser default styles often fail contrast requirements. If people need help, use hint text under the label, kept to one short sentence.

Other details from the GOV.UK text input guidance:

• Match field width to the expected answer. A postcode box should look like it wants a postcode.
• Set the autocomplete attribute so browsers can fill in names, addresses and emails. GOV.UK notes this is required under WCAG 2.2 success criterion 1.3.5 where a relevant input purpose exists.
• Never block copy and paste.
• Turn spellcheck off for names, email addresses and reference numbers.

Layout: one column, one thing at a time

NN/g recommends a single column with one field per row, allowing short related fields such as town and postcode to share a line. Group related fields under a heading, and keep optional fields to one or two, marked “(optional)”. People should never discover a field was required by getting an error.

For longer forms, GOV.UK’s starting point is one question per page. It helps people focus, makes errors easier to handle, and works well on phones. Each page needs a heading, a back link and a button labelled “Continue”. Group questions on one page only when research shows your users cope with it.

NN/g also advises against Reset and Clear buttons, because wiping a form by accident is a bigger risk than wanting to start again. If you need a Cancel button, make it less prominent than the main action.

Errors that help people fix things

The GOV.UK error message guidance is the most detailed public advice on this. The main rules:

• Show each error next to its field, and list all errors in a summary at the top of the page, using the same words in both places.
• Say what went wrong and how to fix it. Use an instruction for empty fields (“Enter your first name”) and a description for wrong answers (“First name must be 35 characters or less”).
• Be specific. A blank field, a too-long answer and a wrong format each need their own message.
• Avoid “invalid”, “forbidden” and “you forgot”. Leave out “please” and “sorry”, and don’t joke (“Oops”).
• Never clear fields when showing errors. Keep what people typed so they can correct it.

NN/g adds that errors should be signalled in more than one way, not by colour alone: outline the field, use red text and heavier type. Some people can’t see red, and colour alone fails accessibility rules.

A worked example

An example (illustration only). A dog-grooming salon’s booking form has 14 fields: title, first name, surname, email, confirm email, phone, mobile, address line 1, address line 2, town, postcode, dog’s name, breed, and “How did you hear about us?”. All are required, labels sit inside the boxes as placeholders, and a failed submit shows “Please fix the errors below” in red and clears both email fields.

Reviewing each field, the owner finds she never posts anything, so the address goes. She texts reminders, so one phone field stays. Title, confirm email and the marketing question go, the last moving to an optional question after booking. The new form has six fields: first name, surname, email, mobile, dog’s name and breed, with visible labels above each box and autocomplete set on the contact fields.

Errors now appear beside each field and in a summary at the top, for instance “Enter your mobile number” and “Enter an email address in the correct format, like name@example.com”, and nothing typed is lost.

Common mistakes

• Asking for data “in case it’s useful later”.
• Using placeholder text instead of labels.
• Marking every field with an asterisk instead of marking the few optional ones.
• Generic errors such as “This field is required” or “Invalid input”.
• Showing errors only in a banner at the top, far from the field.
• Splitting dates or phone numbers into fiddly boxes without testing them.
• Blocking paste in password or email fields.

When to bend these rules

One question per page suits public services, long applications and anything people do once. For a two-field newsletter sign-up or a short contact form, a single page is fine. Internal tools used all day by trained staff may benefit from denser layouts, which GOV.UK itself acknowledges when it says research will tell you when pages can be grouped. The safest approach is to start from these defaults and change them only when testing with your own users gives you a reason.