Write the supporting content for your form
As well as questions, your form or service may need an introduction, help text, error messages and a confirmation or thank you page. Think about content across other channels too.
Name your form
If you have not already done so, name your form or service. (See the GOV.UK guidance on Naming your service.)
Focus on the task, on what the user wants to do.
Introduce the form
Introduce and explain your form or service to users. This is your chance to stop the wrong people filling in the form and to set expectations.
You could try a start page, like the GOV.UK start page pattern. (We are developing an NHS start page pattern for the service manual in GitHub.) Be aware that users often ignore text under the start button (and any "Continue" buttons).
Also, user journeys rarely start with the start page and many forms or services do not need a special start page. Think about how users will get to your form or service as well as how to introduce it.
Give users help in context
If users need help or guidance with filling in a question, do not link to something labelled "help". Add just enough help text where they need it - and only if you see in research that they need it.
Answer users' questions in context, like:
- "What's this?"
- "Why do you want this information?"
- "Where can I find this?"
Use it to explain:
- any necessary jargon
- where to find their NHS number
- what format users should give information in
- what you’ll do with personal information
- the consequences of making 1 choice over another
Good help text saves having to write error messages.
Bear in mind that users may miss the help text. Sometimes a filter question will work better.
If you have to explain your interface, it needs more work.
How to add help text
We do not recommend tool tips. They can be hard for users to see and are not accessible.
Instead you can:
- add hint text as a part of other form inputs, such as text inputs, radios and checkboxes, for help that's relevant to most of your users
- use the details component to reveal expanding help text - this is useful if the help text is only relevant for some users
Use error messages to explain what went wrong
Think of error messages as a step in the conversation. Tell the user how to fix the problem as soon as you can.
If you begin prototyping with 1 thing per page, you can deal with errors for 1 thing at a time.
Read more about error messages in the service manual.
End with a confirmation or thank you page
Consider how you can reassure users they have completed the form and help them understand what to do next.
You could try:
- a confirmation page, like the GOV.UK confirmation page pattern (we are developing an NHS confirmation page pattern for the service manual in GitHub)
- a summary list to summarise users' responses and let them check their answers, as in the GOV.UK check answers pattern
- pausing to allow users to reflect, for example, for a declaration or "signature"
Look at your content across channels
Think beyond the form. For the user, it is likely to be a cross-channel experience. Remember to make your on and offline content consistent, including:
- paper or downloadable forms
- introductory emails or letters
- confirmation emails or text messages
- call centre scripts
- follow up emails or letters
Read more about writing content for transactions
GOV.UK has some good guidance on designing how GOV.UK content and transactions work together.
Would you like to contribute to this guidance?
Please let us know how this has worked for you and, in particular, if you have research findings to share. This will help us improve it for everyone.
Before you start, you will need a GitHub account. It's an open forum where we collect feedback.