Forms

We aim to ensure that our customers can complete any online transaction the first time unaided. It is important that any online forms are high quality, accessible, easy to use and built around customer needs.

This document outlines the design standards and design patterns to use when designing a new form or assessing an existing form.

Form structure

  • Know why you're asking every question (why does the service need that information, who uses it and what for, how will you check the information is accurate, how will you keep it up to date)
  • Design for the most common scenarios first (order of questions, most users should have a simple, quick path, use branching to hide questions)
  • Start with one thing per page (one piece of information, one decision to make, one question to answer). Note, this might vary depending on type of form.
  • Structure your form to help users
See https://www.gov.uk/service-manual/user-centred-design/resources/patterns/form-structure.html

Design components and patterns

Use GDS recommended components and patterns for commonly occurring data such as name, dates, addresses etc. keeping forms as simple as possible.

  • Form questions - Names, Dates, Addresses, NI numbers, Email addresses, Gender and sex, Help text
  • Account management – Usernames, Create a user account, Create a username, Create a password, Email confirmation loops, Knowledge-based authentication, Transaction flow
  • Progress indicators - Start pages, Check your answers pages, Confirmation pages, Feedback pages
See https://design-system.service.gov.uk/components
See https://design-system.service.gov.uk/patterns/

Page structure

  • Use one column only
  • Be careful writing out too many instructions on a page. Users will not read them. Make use of expanding text to remove clutter from the page.
  • Ask personal questions towards the end. On most of the current forms we ask for contact details on the last page.
  • Sentence case is easier to read than title case and never use full uppercase
  • Try and move background information and detailed instructions to a web page instead rather than on the form
  • Keep the form simple and clutter free
  • Remove unnecessary navigation and text
  • Choose appropriate language for the forms and use plain English

Unnecessary data capture

  • Keep questions within the scope of the form
  • Only ask for information that is absolutely necessary
  • Avoid excessive steps
  • Reduce field lengths and group information logically
  • Group related information such as personal details to help the flow of questions

Field labelling

  • Labels should be short and direct. Do not use colons at the end of labels.
  • If the purpose of a label is simple, such as name or email address, then a word or two will be fine. However a phrase or sentence might be necessary to eliminate ambiguity on some of the more complex fields
  • Order the labels logically, reflecting the natural flow of a conversation

Optional and mandatory fields

  • For any mandatory fields add ‘(required)’ or similar to the field label
  • Only ask for the information you absolutely need but if you do ask for optional information, add '(optional)' to the end of your field label

Validation

  • Implement server-side and client-side validation. Consider using script to track user input so it can be validated as they type so the user gets immediate feedback
  • Provide validation error messages for information that is incorrect or blank using colour, usually red, and visual aid iconography such as an or warning sign beside where the error occurred
  • Provide validation success messages to alert the user to correctly completed input providing instant feedback and validation. Emphasize success messages through colour, usually green, and visual aid iconography such as a

Field prefills and placeholder text

  • Don’t use field prefills or placeholder text

Correct use of form fields

  • Provide the appropriate type of input field based on what is being requested. Each type of input field has its own characteristics, which users are accustomed to. For instance, use radio buttons if only one option of several is permitted, and check boxes if multiple choices are allowed.
  • Important address capture should not be provided by free text entry but aided by postcode look up solutions

Name and title

  • Use a single name field called ‘Full name’ if possible because it can accommodate the broadest range of name types and requires less effort for users to understand
  • Avoid asking for people’s title. It’s extra work for users and you’re forcing them to potentially reveal their gender and marital status, which they may not want to do.

Radio buttons v select list (dropdown)

  • Use radio buttons for 5 or fewer options rather than a select (dropdown) list

List fields

  • Use vertical list controls for consistency

Using Fieldsets with Radio buttons and checkboxes

  • Fieldsets and legends work together to tell screen readers that a group of form fields relate to each other, and to provide a label for the group
  • You should use a fieldset element when you have a single multiple choice question when using radio buttons or checkboxes. Do not use them when you have a single form field that asks for a single piece of information.

Field help text

  • Use field help to add in any hints for the user on how to fill in the field
  • Do not just repeat or reword the field title
  • Use field help to provide more information to the user rather than making your field titles long and rambling
  • Help text can provide context that the field label may not provide
  • Not all fields need help text
  • Use expanding text to provide further information if needed rather than making the help text too long and add in below the field as seen in the screenshots below.
  • Make the help text succinct and easy to read
  • Make sure that a user can tab through any help icons to aid accessibility and screen readers

User guidance and instructions

  • Any user guidance or detailed information should be provided on an accompanying council website page (and maintained in the website CMS) and not added to the first page of a form. On the web page it would be useful to indicate how long a form might take a user to fill in.
  • Sometimes it is necessary to add some important information on the first page of the form to avoid any confusion if the user has come directly to the form (and not via the website) but always try and link back to a web page on the council website.

Data fields

  • Various calendar picker controls (Date field, Weekday view, Month view) can be used for events close to the present time or if the user needs to know the day as well as the date, be able to compare dates or be able to enter date ranges.
  • Date picker accessibility and use on a mobile can be problematic so these should be implemented with caution and tested well on a mobile site.
  • Often preferable to use a date picker field with separate day field / month field / year field and all validated as such. This type of control can be used for memorable dates or known dates and for mobile use.
  • If you don’t need the exact date and you are asking for dates that users might struggle to remember allow them to enter an approximate date such as January 2020 using a text input field.

Mask controls

  • Try to avoid using mask controls where possible

Branching

  • Use ‘branching’ questions so people only have to answer questions that are relevant to them

Confirmation page (once a form has been submitted)

  • Details of what happens next and when
  • Contact details for the service
  • Links to information or services that users are likely to need next
  • Link to a feedback page

Design techniques

Look at:

  • Designing using wireframes – you can use software packages to help with this
  • Develop prototypes before building
  • Do user testing on the public
  • Act on customer feedback to make improvements

Monitor, iterate and improve

  • Test a range of performance improvement initiatives and monitor to see which work well
  • Implement the best performing solutions widely and then repeat this process relentlessly
  • Monitor and act upon user feedback
  • Carry out A/B testing
  • Use an iterative approach to increase the pace of improvement and minimise the risk of failure

If you're unsure, check with the Digital Development Team for advice.