eForm design patterns and standards

The information on this page is currently under review. For the most up to date information on forms visit GOV.UK's Service Manual - Structuring forms

What is a form? What is a survey?

A form is a transactional process where a customer is submitting information in order for something to happen (such as an application or a renewal)
A survey is seeking the customer’s opinion to inform service delivery but won’t lead to a direct action for the customer (apart from, perhaps, an entry into a prize draw).

Start pages

This is a single point of entry to the transaction which tells the customer what they can expect when they press ‘start’. It should be accessed from a relevant content page on the website (in Umbraco) and should:

describe the service
set expectations
establish eligibility.

The Government Digital Service guidelines can be applied to the start page.

Form structure

use questions or statements but be consistent throughout the form
ask for as little information from the customer as you can, while still being able to complete the transaction
keep things short and straightforward and explain why you’re asking things if the reason is not obvious.

Think about the structure of the form before you start to build it.

how many questions are there?
will users need to answer the questions in fixed order?
will they need to complete the transaction in a single session? If the transaction requires an intervention or human action by the service at some point then this should be designed as a process in govService
will their answers affect other parts of the transaction or cause them to abandon the transaction?
will they need to add items from a list, or change the order of items?
do any parts of the transaction take place offline/
at what point is the transaction complete?

Design patterns for grouping of questions, accordion forms or hybrid layouts are currently in development. Some information on options from the Government Digital Service to help inform your decision.

Field labels

These should be located to the left of the field.

Placeholder text

Don’t put placeholder text in the fields where it will disappear once the customer makes the field active.

See guidance on help text for how to display placeholder or hint text.

Progress indicators

Use a progress bar across the top of the form and make sure the default page numbers are changed to clear, plain text labels (for example it should be ‘About you’ not ‘page 1’.

The progress bar becomes less useful to the customer with complicated forms with several routes through them. For these forms you’ll need to consider how progress is shown accurately.

Help text

Keep help text short and speak to the customer in their everyday language. Customers are unlikely to read more than three lines of text.

Explain:

legal jargon
unfamiliar concepts
where to find obscure information
what format the information should be given in
what you do with personal information.

If you need to explain the interface or the way to use the form then it isn’t simple enough.

Inline text

This help should be a short clear text positioned immediately next to the part of the page it relates to. Use this for help relevant to the majority of users. Position between the label and the field so sighted and screen reader customers read before they get to the field itself. You should ensure that the text can be read by screen readers.

Hidden help text

A short link that expands into more detailed help when clicked on. Use this to make your page easier to scan but don’t hide text if a majority of users will need it.

Complex decisions and detailed help

If the customer is making a complex decision requiring more detailed help you may need to create a hidden help option which expands to provide the guidance. Make sure users can:

access help before and during the transaction
can get back to the transaction without losing their place
are shown help that’s relevant to their current situation.

Detailed help should not be used to explain the interface.

Names

A single name field should be presented unless two are needed for processing into back office systems.

When two are used these should be ‘First name’ and ‘Last name’.

Don’t ask for middle names or titles unless vital to a back office system.

Dates and date pickers

Not all dates are the same – choose the format appropriate for the kind of date you’re asking about.

Memorable dates

For memorable dates – such as date of birth – the simplest option is to provide text fields for the customer to type in. Include help text between the Label and Field to help the customer understand the format needed. This should be DD MM YYYY. Use three fields rather than one.

Copied dates

If you require a date to match exactly the way it is provided on another document allow the customer to copy this across. Use one field to allow this.

Approximate dates

If you don’t need an exact date or the customer is unlikely to remember – for example, when did you start your first job or when did you move into your home – then allow them to enter approximate dates, such as June 1996.

Relative dates

Some dates are relative to today’s or another day’s date and make sense in bookings. Allow customers to enter or select relative dates like ‘tomorrow’ or ‘four days later’. If the day is important show this too.

Calendar controls

Only use calendar controls for near past or future dates where the day of the week is relevant. The main use is appointment booking.

If the calendar also needs to show availability embed it in the page and make it large enough for the information to be readable.

JavaScript should never be the only input option.

Formatting dates

The default format is:

8 July 2014

Periods of time should be:

8 July to 9 August 2014.

See the Content Standard and style guide for more information on formatting of dates.

Validating dates

When you validate dates check:

date ranges – the dates are consecutive
past dates – check the date is in the past
future dates – check the date is in the future
mistyped dates – if the date is obviously mistyped (for example days and months transposed), warn the customer.

Addresses and address look-up

Ideally use an address finder, or postcode lookup, with a manual option for people with badly formed addresses in the Royal Mail database.

These allows users to find a UK address by inputting their postcode (and optional other information) and selecting the address from a list.

If this format can’t be used, then use a single text box. Only use multiple field manual entry address boxes where the back office system it links to requires it.

Text boxes

These should be long enough that customers can read all of the text without scrolling.

Text areas

These should be large enough that customers can read all of the text without scrolling.

Check boxes, radio buttons and drop-downs

Always display radio buttons or check boxes in a vertical list. Don’t have a pre-selected option on either type unless there is a user-centred reason to.

Use radio buttons to allow users to select a single option from a list.

Use check boxes to select either on/off toggles or multiple selections (including zero and one selections). Make it clear with words when users can select multiple options (‘select all that apply’)

Don’t use drop-downs – use radio buttons instead.

Mandatory

You should only ask for information you need and where a field is optional, you should label it as such.

Review or summary pages

The review or summary page should allow users to check and edit the answers they’ve given before they submit the form. It should display in the same browser window and should make it clear that the transaction is not yet complete.

The submit button on this page should be very clearly marked with the action of the transactions – ‘apply for a waste permit’, ‘apply for a skip licence’, ‘renew your Blue badge’. Do not use ‘submit’ or ‘confirm’.

You need to consider customer security on the review or summary page and may need to obfuscate parts of the data to avoid it being read by the wrong people. Make sure you have assessed the security risk with the service and other relevant colleagues (such as legal) where appropriate.

Progress and Submit buttons

You should aim to use only two buttons per page of the form – ‘save and continue’ and ‘go back to previous step’.

The primary action button (save and continue) should be aligned to the left edge of the form, in the customer’s line of sight.

On the review or summary page the button should be clearly labelled with the action of the transaction. See the review or summary pages section of the guide for more information.

Form validation

Summarise validation errors in a box at the top of the page. Use jump links in the summary to reach errors in the form and apply the same colour to the area the error occurred in.

Make sure error messages make sense when read by screen readers.

Make sure errors don’t clear pre-filled fields.

End pages and reference numbers

This is the very final stage after a customer has completed the transaction. It should help to frame the service and capture satisfaction and comments. It should be on the website (in Umbraco).

It should include:

confirmation of the transaction a customer has just completed
provide a reference number (automatically generated in govService)
detail how the reference number can be used by the customer to follow up if needed
detail the next stage and how long a customer can expect before an action is completed or they receive something. These can be average service delivery times (for example, how many days until we fill a pothole). Set expectations realistically. Ensure the service is providing up to date delivery times frequently.
a request for the customer to provide feedback and satisfaction with the digital transaction.

The end page should provide a sensible route back to the website (homepage, section landing page).

Confirmation emails to customer

The confirmation email to customers should include:

confirmation of the transaction a customer has just completed
the reference number (automatically generated in govService)
detail how the reference number can be used by the customer to follow up if needed
detail the next stage and how long a customer can expect before an action is completed or they receive something. These can be average service delivery times but should set expectations realistically. Ensure the service is providing up to date delivery times frequently.
a request for the customer to provide feedback and satisfaction with the digital transaction.
an invite for the customer to use the email address provided to sign up to emailme.

Confirmation email to service

The confirmation email to services should alert them that a form has been submitted. It should include:

the name of the transaction
the reference number of the form submitted
how they get to the data and what formats it is available in
a reminder of the service delivery expectation which has been set with the customer
and how to contact the digital team if there is a problem with the form or data.

Analytics and drop-off rates

Completion rate

Analytics should be set up so that completion rates for the whole transaction can be gathered but also broken down into more detail, including:

number of people starting the form
number of people submitting a completed form
the drop-out rate at each stage of the form.

The data should be used to inform ongoing usability and A/B or multi-variant testing to continuously improve the service and completion rate.

There is more detailed information on collecting data and analysing completion rate in the Government Service Design Manual.

Digital take-up (channel shift)

You should measure the digital take-up of a service monthly (where possible). You do this by taking the number of completed digital transactions in the calendar month and dividing it by the total number of transactions in the same month. Express this as a percentage.

There is more about digital take-up in the Government Digital Service Manual