You can assume that users know how forms work. For example, you do not need to explain how to use links, dropdowns and buttons.
Only ask a question if the information is needed to deliver a service and you know:
- why the information is needed
- what will happen to it
- which users need to provide the information
Any information that a user will need to fill in the form should be listed on the lead-in page. For example, a particular type of reference number.
Lead-in pages should use the name of the thing as the title and URL. For example:
- page title: 'Dog licences'
- page URL: '/dog-licences'
If you think some users might get to the form without going through the lead-in page, you can also put vital information at the beginning of the form in a 'Before you start' section.
Give your form an active title. Use a verb and the name of the thing. For example:
- form title: 'Apply for a dog licence'
- form URL: '/apply-for-dog-licence'
Do not use the words 'form' or 'service' in the title or URL.
Think about your main user group
Think about who's most likely to be using the form and tailor it to them. For example, is your form most likely to be used by a member of the public or a professional making a referral for someone else.
If the form could be used by both people answering for themselves and people answering for someone else, you'll have to decide whether it's best to have:
- 2 separate routes through the form
- text at the beginning that says 'If you're answering for someone else, answer the questions with their details not your own'.
Start with eligibility
Start the form with any questions that check eligibility. This is to avoid a user spending time answering other questions, only to find out they're not eligible later in the form.
Group questions together
Divide your form into sections, grouping a few related questions together in each section.
Give each section an active, clear heading to cover the questions that are in it. For example, 'Your details' or 'About the problem'.
Use branching logic
If a field is only relevant to certain users, use logic on that field so that it's only shown to those users, based on how previous fields are answered.
This is called 'branching logic' and means a user only answers questions that are relevant to them.
Every form field must have a label that tells the user what they should put into the field. It must:
- be short and direct
- use sentence case
- go above the form field
- remain visible at all times
Try to phrase the label without the need for a question mark. This makes the label easier to read. For example, 'Your full name', rather than 'What's your full name?'.
However, some labels do work better as questions, such as 'Have you told your landlord about the problem?'. Use your judgement on what works best.
All fields are mandatory unless marked as optional. For example, 'Your phone number (optional)'.
Hint text is provided alongside a field label to help users understand and complete the field.
Before using hint text, try to improve the field label wording. Only use hint text when there's a clear user need.
You can use hint text to:
- give an example of a valid answer, such as: 'For example, QQ 12 34 56 C' on a National Insurance number field
- explain how to use the field such as: 'Select all that apply' on checkbox fields
- explain a term used in the field label
- tell the user where they can find or look up information, such as their postcode
- explain how the information will be used, such as: 'We'll use this email address to send you a copy of your form'
Do not use hint text for:
- information that the user must have
- explanations longer than a few words
- information not directly related to the field
How to write hint text
Write hint text as a single, short sentence, with a capital letter at the beginning and a full stop at the end.
Avoid using links in hint text, if possible. Screen readers will read out the link text but may not announce that it's a link.
Use an error message when there's a validation error on a field. This helps the user understand what went wrong and how to fix the issue.
For example, when the user has:
- left a mandatory field blank
- entered information that does not match the format required
- entered too many or too few words
- used characters that are not allowed
Do not use error messages to tell the user about a problem that they cannot fix. For example:
- about a problem with the service
- when they do not have permission to do something
Take the user to a page that explains the problem and provides information about what they can do instead.
Minimise errors
Try to minimise errors. Use clear, plain English on field labels and hint text to make fields easy to fill in. If you want the user to enter information in a certain format, put that format into the field label or hint text.
Be forgiving with what's acceptable, if this will not cause any other issues. For example, accept postcodes with or without spaces and names with an apostrophe or accent.
How to write an error message
Error messages should:
- be specific and include language directly from the field label
- use simple language to explain the error and what the user can do to fix it
- make sense by themselves
- be one sentence long, with no full stop at the end
If the error message has to be more than one sentence long, use full stops at the end of the sentences.
Do not use:
- technical jargon, such as 'form post error' or 'error 0x0000000643'
- words like 'forbidden', 'illegal', 'you forgot' and 'prohibited'
- 'please' because it implies a choice
- 'sorry' because it does not help fix the problem
- humorous, informal language like 'oops'
- general messages such as 'An error occurred', 'Answer the question' and 'Fill in the field'
- a format example if there's an example on the field already
If information is missing
Use:
- 'You need to tell us...'. For example, 'You need to tell us your full name'
- 'You need to describe...'. For example, 'You need to describe the problem'
- 'You need to choose...'. For example, 'You need to choose an appointment'
If information is in the wrong format
Where the correct format is:
- shown on the field, use 'This must be a….', for example, 'This must be a National Insurance number'
- not shown on the field, use 'This must be a [x], using the format [x], for example, 'This must be an email address, using the format name@example.com'.
Fields that we use regularly are listed on our common form fields page, along with their error messages.
Word count, address lookup and date and time have standard error messages that are not covered here.
Follow our links guidance in the A to Z of style.
Same tab or new tab
If you want a user to leave the form, such as at an end point, have links open in the same tab.
If you do not want a user to lose their place in the form when they open a link, you can have it open in a new tab.
Write field labels, hint text, error messages, guidance and any other text using our design principles and A to Z of style.
An autocomplete attribute tells the browser if it can automatically fill in form fields using information previously entered by the user and if so, what information is expected in each field.
You should add an autocomplete attribute to any form fields that collect personal information. For example, use the attribute:
- 'name' for name
- 'email' for email
- 'tel' for phone number
- 'bday' for date of birth