Forms

1Introduction

A form is a group of related components that allow users to provide data and/or configure any number of options. 

Users should be able to use forms with as little difficulty and mental effort as possible. Form behaviour and layout consistency are key to achieving this goal. This is why we ask that, when building forms, you follow the Standards outlined in this section - no matter how simple or complex your form is.

A note on terminology

MUST: You must not deviate from the Design System.

If you need a new variant of a component or pattern, please contact the Design System team outlining the variant you need and why. 

We will work with you to either suggest an alternative approach, update the Design System or support your team to make the required updates.

SHOULD: You are strongly encouraged not to deviate from the Design System, unless there is a good reason.

Carefully consider the implications and deviate only when absolutely necessary. 

Consider speaking to the Design System team for advice first.

A note on Standards implementation

Several Standards are 'by default' taken care of by the Design System (DS). These have not been marked here, but will eventually be marked accordingly. This means that, unless a downstream team changes our implementation, the Standard is automatically satisfied by using the default implementation provided by the DS.

However, if a downstream team chooses to develop their own implementation, they will have to ensure adherence to those Standards.

2Anatomy of a form

A form can be made up of some or all of the following:

1. Form error summary. Appears after a failed form submission; outlines all errors and links to the respective form inputs.

2. Sections. Break up long forms into smaller blocks that are easier to process.

3. Fieldsets. Group closely related form inputs, eg. a group of inputs that allows the user to enter an address.

4. Input components. Enable users to provide data and/or configure options.

5. Contextual help. Help text that appears in an overlay, providing information about the relevant field(s).

6. Hint text. Short contextual cues, to assist the user in providing the right data. 

7. Error message. Contextual error message, related to the field directly below.

8. Buttons. Allow users to submit, save or exit a form.

3General form Standards

This section outlines Standards that apply to all forms. Individual form components may have their own Standards, which you must also refer to.

Labels, Hint text and Section dividers

1.0 You must use sentence-style capitalisation.

1.1 You must not use colons or full stops (periods) after labels or section titles.

1.2 You must not truncate labels, Hint text or section titles.

1.3 Labels must not span multiple lines.

1.4 Labels should be up to 5 words. Use Hint text or Contextual help to provide more detail.

1.5 You must not use placeholder or ‘default’ text. Placeholder text results in poor user experience and accessibility. Use the Hint text component instead.

1.6 You should not disable the option to copy from or paste into any form field. Except for Password fields, which do not allow copying by design.

1.7 You should not disable autocomplete, unless it poses a specific security concern.

1.8 If you have to disable autocomplete, you must do so at the lowest level possible. Specifically, you must not disable autocomplete for the entire form, but only for those fields that pose a security concern.

1.9 You must not pre-fill form inputs, unless they represent data that already exists in the system. In other words, you must not introduce new data ‘by default’, because a user may overlook a pre-filled input. The form will pass validation with the default values, introducing new data to the system without the user’s knowledge. For example, you must not pre-select consent for receiving a newsletter during a sign-up flow, but you should do so on an existing user profile page, if that’s what they selected when they signed up.

Language

2.0 You must use the same words when you mean the same thing. Users should not have to wonder whether different words or actions mean the same thing. Maintain consistency within your application and consider the context of use. For example: Consider terminology used in other applications your audience is familiar with. Is there a glossary? Would Contextual help be appropriate?

2.1 You should avoid or explain acronyms and jargon where possible. Consider industry conventions, but do not assume that all your users will be familiar with jargon or acronyms. Use Hint text or Contextual help when appropriate to explain acronyms and terms which users may not be familiar with.

2.2 You should test your language with both novice and expert users. This does not refer only to IT literacy, but also experience in their field. An expert user is more likely to be familiar with established terms and processes. On the other hand, a novice user (or someone who is an expert in their field but not in the particular process you’re testing) may need more guidance or make more mistakes under pressure.

Consider the wider context

Always consider the wider context in which your forms exist. This includes not just your own service, but also relevant services, offline processes, and the wider organisational culture.

3.0 For example, if you are converting a form that currently only exists on paper, don’t just translate it to an online form without considering how you can improve the user experience and even transform how your service is delivered.

3.1 You must carefully consider why you’re asking users for each item of information. Challenge all questions, with the aim of simplifying the overall user experience. How will each item of information be used? Where is it saved? Can it be edited at a later stage? Could it be retrieved from a database instead? 

You must consider the most appropriate way to capture the answer to each question. Guide your users and ensure data quality. For instance, an address is best captured by multiple single-line text fields, rather than a single text area. Even though they may make your form longer, multiple fields help direct users and validate their answers, eg. by ensuring they haven’t forgotten the postcode.

Printing

4.0 If there is a user need to print out information supplied via a form, your app should provide the relevant print functionality, with appropriate formatting. This should be designed to strip out information and UI that's not needed, so that your users can print out a proper document, rather than a web page.

4Form layout

Long forms

While you should always aim to minimise the amount of input required by the user, there may be times when you have to work with long forms. 

5.0 You must always consider the context of use before deciding which techniques to use for managing long forms.

5.1 You should test a working version of the form with your users, where possible.

There are various techniques to make such forms more manageable, but you should always test your approach with your users, because a lot depends on the context of use. For example, while for some applications it may make sense to paginate a long form, for highly complex data forms in a Defence environment it may be necessary to frequently check previously entered values, which would be very disruptive with a paginated form.

Splitting up long forms

Consider using one or more of the following techniques to make a long form more manageable: 

• Group related inputs together

• Introduce collapsible sections

• Split the form into multiple columns

• Paginate (split up the form over multiple steps or pages)

We are developing Patterns to provide best-use examples of these techniques. Sign up to our monthly newsletter to be notified when we publish these.

Single vs. multi-column forms

Multi-column form layouts are often appropriate in complex Defence settings. Single column forms, however, are simpler to design and generally recommended for shorter forms.

To decide which approach is more appropriate, you should consider the following:

• Task at hand

  Does it only require serial data input or does the user need to constantly refer to previously entered data?

• Total number of input fields

  If it all fits into a single screen, is it really necessary to split into multiple columns?

• Average input length

  Several small number input components can easily fit into multiple columns, but long textual narratives are easier to edit in full-width components

• Connections between input fields

  Can fields be organised into small, coherent groups which can be meaningfully arranged over multiple columns without losing their connection? 

• Target screen size and technology

  If the majority of your users will be completing the form on a handheld device and your technology does not allow a responsive layout, what effect would multiple columns have on the user experience?

Laying out forms over multiple columns

6.0 You must ensure your form tab order works correctly and follows your intended form layout.

In practice, this means making sure that:

1. Columns, nested columns and Fieldsets are in the right tab order in relation to their neighbouring components

2. All components inside a column follow the intended tab order

3. Tabbing through your entire form is seamless - meaning that you can tab in and out of the Form without having to use a mouse

When laying out forms over multiple columns, consider the best way to group your form fields (horizontally or vertically) and avoid mixing different layouts.

While your form layout will influence the field order, it should not dictate how you group the fields. Grouping should only depend on the logical relationships between the fields themselves. To achieve this within a multi-column layout, you can use the Fieldset component.

When using multi-column layouts, consider the following guidelines:

Sample form templates

Multi-column layout

Design Notes

• Mixing numbers and columns is ok, provided that there is a clear way of filling the form in (left-to-right, top-to-bottom in this instance).

• Toggle for advanced options, keeping the form as simple as possible, with only the most frequently used inputs visible initially (Progressive Disclosure).

• Additional form actions (such as "Add another item") using tertiary buttons

• Disabled inputs confirm details that the user doesn't have permission to change but which may need double-checking.

• Buttons left-aligned

• Primary button first on the left

• Cancel as secondary button

Single narrow column layout

Design notes

• Stacked buttons

• All buttons full-width, regardless of the length of their label

• Primary button first

Dialog

Design notes

• Buttons right-aligned

• Special button top and bottom margins for Modal

Multi-step form

Design notes

• Buttons right-aligned

• Primary button first on the right

• Icon-right button variant used to denote this is a multi-step form

Two column layout with Fieldsets

Design notes

• Logical grouping and labelling supported by Section dividers and Fieldsets

• Buttons left-aligned

• Primary button first on the left

• Cancel action uses Secondary button

Destructive action confirmation pattern

Design Notes

• Uses a Dialog component

• Dialog appears centred on the user's window, disabling the parent application UI behind it

• The parent application UI remains in its current state whilst the confirmation dialog is visible

• If the user chooses to not proceed with a destructive action (e.g. "Keep event"), the confirmation Dialog disappears and the user is back to the same application state they were in before clicking on the destructive link

• Users must interact with the dialog window before they return to the parent application

5Form alignment and spacing

Humans instinctively tend to look for patterns, structure and order. When we meet a friend, we don’t recognise their hair, eyes and nose - we recognise their face. 

In a similar way, the components of a form as a whole are perceived differently than the same components on their own. A user’s perception of the ‘whole’ determines how they will interact with the form. Appropriate alignment and spacing helps them navigate through your form and make sense of its structure and groupings. 

Our alignment and spacing Standards are based on the Gestalt principles, with the intention of helping users quickly identify groupings and the most efficient way of filling in a form.

Alignment

7.0 All form columns, section dividers, fields and labels must be left aligned.

This is because (in Western cultures) it is easier for users to scan a form vertically and navigate through it with a mouse when everything is left aligned.

7.1 Input field widths must reflect the expected input length.

For example, when asking for an address, the input field width for the first line of the address should be wider than the postcode input  field, reflecting the difference in the expected input length.

7.2 You must not use more than four different widths for form components.

While input field widths must reflect the expected input length, too many distinct widths result in visual ‘noise’ and have the opposite effect than intended. To maintain visual balance use components that correspond to 100%, 75%, 50% or 25% of your form width, with the necessary spacing between them as described in the next section.

Spacing

8.0 You must ensure all form components are spaced using the margins specified.

8.1 The margin between your form and its container or nearest neighbour must not be smaller than 20 pixels. Where possible, you should aim for a margin of at least 32 pixels. Different contexts may require different margins. In exceptional cases (eg. a small number of fields within a complex interface), you may use a small margin, but no smaller than 20 pixels. Forms may appear as dedicated pages or within a Dialog, a Drawer or a Modal.

A note on borders and margins

This note applies to the active states of all components.

The height for ‘single-line’ inputs in their default state is 46px, including the border.

When a component gets focus (active state), a blue outline is added, resulting in a total height of 58px. 

However, form inputs should not ‘jump around’ as the focus moves between them. In practice this means that the position of a form component in relation to its neighbours does not change, regardless of the state it is in (default or selected). 

This also applies to horizontal margins.

6Submit, validate and show form errors

Our goal is to promote applications that behave in a consistent way, reducing a user’s cognitive load. It’s important to maintain a consistent approach, no matter how simple a form may be - users moving between applications shouldn’t have to change the way they think and work based on which application they are using at any given moment.

This is why we ask that you adhere to these Standards, regardless of how straightforward your forms are - consistency is key, and this applies to form validation as much as any other aspect of form design.

Optional vs mandatory fields

9.0 You should mark all optional fields with “(optional)” appended to their label. Eg. “Notes (optional)”.

9.1 You should not mark mandatory fields. All fields are mandatory, unless marked as optional.

Submitting a form

10.0 You must not disable form submission buttons, except to prevent duplicate submissions as per 10.1. Disabling a form submission button does not clearly communicate the system status; not all users will understand that the button is disabled because of a form validation error.

10.1 Where duplicate form submissions would result in data quality or other issues, you must set the primary form button to its Loading state immediately after a user submits a form. 

However, please note Standard 11.4, on re-enabling the button if form submission fails.

10.2 If your system takes on average more than 5 seconds to process a form submission and display the result, you must set the primary form button to its Wait state immediately after a user submits the form. 

However, please note Standard 11.4, on re-enabling the button if form submission fails.

Form validation, error prevention and error messaging

Since 1994, Jakob Nielsen's general principles for interaction design have become popular rules of thumb for good human-computer interaction design. Our Standards for Form validation, error prevention and error messaging are based on Nielsen’s principles #1: Visibility of system status, #5: Error prevention and #9: Help users recognise, diagnose, and recover from errors.

11.0 The status of the system must always be clear, through appropriate feedback within a reasonable amount of time.

Whenever users interact with a system, they need to know whether the interaction was successful. Did the system actually register a button press? Is it still working on it? Was the data saved? Should they press the button again? 

Feedback can be as simple as showing:

• a spinner once the user has clicked on a button (see 10.2)

• a success message to confirm task completion

• a clear error message if there are validation errors or if the system failed to process the user’s request (see 11.2)

If a form submission merely results in refreshing data on the page, the data refresh must be clear to the user. Bear in mind that the data refreshed may be outside the currently visible part of the screen or that it may refresh so quickly that the user is not aware of the refresh. In such instances you should show a ‘toaster’ confirmation message, a ‘spinner’ for a couple of seconds, or even a ‘fake’ screen refresh, if it helps your users be confident that the form was submitted and the data updated correctly.

11.1 You should prevent user errors by offering suggestions, utilising constraints, and being appropriately flexible.

Both expert users familiar with the process at hand and novice users still learning are prone to making mistakes, especially under pressure. When users move between systems - and especially systems that use different conventions - the chances of making a mistake increase.  For example, entering a date in a mm/dd/yyyy format when the system expects a dd/mm/yyyy format or typing a time using a 12-hour clock when the system uses a 24-hour format are both difficult to validate and could have severe consequences. 

We can reduce such errors using good design. For example, when asking the user to enter a date, show a “(dd/mm/yyyy)” note. When choosing a time, you can immediately display the entered time into 24-hour format, so if a user typed 8:15 you can display as 08:15 or 08.15am. If a user typed 1310 in a time field, you can convert and display as 13:10 or 01.10pm depending on the format your application uses. 

The most appropriate format depends on your application’s users and its wider context (see "Consider the wider context" above). Where possible, you should test a live version of your form with your users in order to validate your assumptions.

11.2 Error messages must be expressed in plain language, indicating the problem and, where possible, constructively suggesting a solution.

11.3 Error messages for individual form fields should not exceed 20 words. 

11.4 If form submission fails or times out, you must show an error message and re-enable the primary form button.

11.5 If form submission fails or times out, your application must retain all entered data, unless doing so poses a specific security concern. 

This is in order to allow the user to re-submit the form without having to re-enter all data. Any non-sensitive data already entered must be retained, including values of Select, Multi-select, Radio button and Checkbox components. Consider if sensitive data (eg. a password) should be requested again. If this is the case, you must also mark the fields that need to be requested again as an error, in order to draw the user’s attention to those fields before they resubmit the form.

11.6 Where possible, you must offer immediate inline field validation, but only after a form field loses focus.

If you can determine that an input fails validation (with or without sending data to the server), you must not wait until a user submits the form to report the error. 

For example, if a date is entered as 35/12/2021 or a username is already taken, show the inline error immediately after focus moves away from the respective form input. Validation must not be real-time (i.e. while the user is still typing their input), as this is likely to become distracting and annoying by constantly reporting errors before a user has finished typing their input.

11.6.1 When offering immediate inline field validation, you must not alter the list of errors at the top of the form.

If the list is not already visible, do not show it. If the list is visible because of an earlier failed submission, do not alter it. Doing so would cause the page to jump around considerably. The list at the top of the form should only be altered as a result of a form submission (see 11.7).

11.7 If a form fails validation after submission, in addition to the inline errors, you must show a list of all errors at the top of the form, and move focus to that area; this includes scrolling the screen as appropriate, so that the list of errors is visible near the top of the screen 

Moving the focus to the list of errors should also ensure that screen readers will announce the error messages and begin at the start of the form, helping users with accessibility requirements understand what has happened. See Design for more information.

11.8 You should avoid ‘Reset’ Buttons that erase unsaved form data. 

If you do need a ‘Reset’ Button, ensure a confirmation dialogue is displayed before erasing all form data.

Character limits

11.9 You should avoid imposing character limits if you can. You should consider where the information entered will be stored and how it will be displayed. 

Design

If a user tries to submit a form which fails validation:

• All fields that fail validation must be set to their error state 

• A summary of all errors must be shown at the top of the form

• The page must scroll automatically to the summary of errors (see auto-scroll animation details below)

• The summary of errors container should have the role attribute set to alert to make assistive technology users aware of this change

Auto-scroll animation

easeInOutCubic, 250mshttps://easings.net/#easeInOutCubic