Forms - Usage

Basic Guidelines

Keep the form as short and simple as possible. Don’t ask for information that can be derived in some other way or collected conveniently at a later date, and question the necessity of optional form components. The conversion rate increases with every field cut from a form.

Present forms in a single column layout to not interrupt the vertical flow. However, short, logically related fields can be presented in the same row (e.g. Credit card number, expiration date and security code).

Group related components together and use a logical order for both fields (e.g. Credit card number – expiration date – security code) and value choices, listing options from simplest operation to most complex, or least risk to most.

Arrange form components from easiest to hardest to fill in (e.g. ask for name and email before introducing more complex information like billing and shipping). Once, users answer simple questions, they will be committed and more likely to complete the form.

For long and complex forms, we recommend splitting them into several pages. This reduces the user’s cognitive load and visual noise. Give the user insight into how many pages they can expect in the process (i.e. display the number of steps, or a percentage of completion via a progress bar).

Consider matching the width of the fields to the size of their expected content (e.g. use small fields for a credit card’s expiration date and security code).

Avoid placeholder text as this raises several usability and accessibility concerns. Instead, explain any input or formatting requirements in the in-line messaging. It’s also important that labels are unique across a page to avoid confusion.

Don’t display the ‘Submit’ Button as disabled even when required fields have not been filled in yet. Without being able to click the Button, the user won’t get any feedback as to why the form can’t be submitted. In addition, disabled elements are not tab- or focusable, so screen reader uses won’t get any information on how to proceed.

Equally, avoid reset and clear buttons, as the risk of accidentally deleting the inputs outweighs the need to start over.

Form Validation

A form validation ensures the information provided by the user matches the defined criteria (i.e. a specific format) for each form field. A validation is triggered only by submitting the form and carried out across the whole form in one go. If an input doesn’t match the requirements of the field, an error message will be shown directly underneath said field.

For accessibility reasons, it’s not recommended to do an in-line validation. For instance, visually impaired users will be unaware of errors appearing after they have left a field if validation happens on blur.

The user must be allowed to browse the form without generating errors (i.e. tabbing through fields without filling them in should not result in an error). A field left empty should be considered valid until the form is submitted and validated.

Example scenario: User filled in the first field, tabbed in and out of the second and is just about to fill in the third.

Error messages need to be specific, concise and helpful, providing a solution on how the user can complete the process.

Please ensure that all required form components are marked as such. We’re using asterisks to mark mandatory fields, and explain the meaning to the user above the form fields. This way, it’s less likely that users will skip required fields and generate errors when submitting the form. It is not necessary to mark fields as optional.

Alignment

The form components must align with the grid system set out in Foundations. They sit in-line with the rest of the text.

In a 12-column grid layout, the form components and the ‘Submit’ Button sit left-aligned within the grid, in-line with the rest of the text. Their width is generally recommended to be set to three columns wide, but can be adjusted to match the length of content they’re expected to receive. The examples below are downscaled proportionally for illustration purposes.