Forms test

Form or 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).

Forms should be built using the Firmstep platform.

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).

Surveys should be built using the council's Consultation Hub.

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.

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?
  • 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?

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.

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.

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. 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 Achieve)
  • 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 Achieve)
  • 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.

Share this page?