Forms

Learn to build forms that follow best practices.

Forms represent the most meaningful interactions we have with our users. These guidelines serve to summarise the wealth of existing research. When it comes to forms, simple is best.

Example

Collecting information

It's important to ask the right questions so that everyone can use and complete the form as quickly as possible. GOV.UK has some great guidance on this (opens in new window) .

Always ask for only information you definitely need.
Always put the questions in a sensible order.
- For example, put payment details after delivery details.
Always start with questions that will let users know if they’re not eligible.
- Avoids wasting people's time.

Structuring form layout

When structuring forms, start simple.

Always align buttons to the left edge of the last input.
- It’s where users naturally look for them which also makes it easier for screen magnifier users.
Always use a chevron on buttons that lead to the next page of a multi part form.
- See CTA Button.
Avoid multi column form layouts.
- They’re error prone, slower to use and can cause abandonment (opens in new window) .

The Stack component should be used to control the vertical spacing between form fields.

Grouping form fields with fieldsets

Fieldsets can be used to group related form fields, for example address or contact information. A legend element describes the group of inputs and should always be the first element within a fieldset.

Form fields do not always need to be grouped but if they are this should always be done using a fieldset.

There is no fieldset component. Instead use the Card, Stack, and Heading components and change the semantic elements using the as prop from Styled Components (opens in new window) .

There is an example of this in the Card component documentation.

Hint text

Always use hint text to tell users why you’re asking them for certain information if it’s not obvious.
Always use hint text when users are more likely to make a mistake.
- Such as having to satisfy a complex set of password rules.

Fields

The way we design our fields can help inform users what is being asked of them and why. We have tried to build as much best practice into our form components as possible.

Labels

Always give fields a label.
- Sighted users can see them, visually-impaired users can hear them and motor-impaired users can more easily set focus to the related input.
Never mark required fields, instead mark optional ones.
Never use placeholders.
- They are problematic (opens in new window) - both as makeshift labels and as a means of storing additional hint text.

Disabled states

Nebula's fields and buttons don't have disabled states. The main reason for this choice is that from accessibility point of view disabled buttons give a poor user experience. In most cases screen readers skip the field because it isn’t focusable and keyboards won’t register it, and in other cases the contrast on the component is so low it can’t be read, rendering it unclear on what the user needs to do.

For buttons, we recommend using the default state and then relying on error handling in your form, this allows the user to get adequate feedback on what they need to do if they have missed something.

For form fields, we recommend reframing the problem. Is there a better way to design the experience to remove the need for a deactivated state? For example a great way to communicate with the user on why something isn’t available is through descriptive copy.

Because you have told us you only want green energy, you cannot select coal as an energy source.

If you would like to select non-green energy instead, you can update your preferences here.

In the instance where you have a form field that requires additional information when in a particular state, we advise using a conditional reveal (opens in new window) .

Validating data

Many of the principles above serve to help users avoid validation issues, but inevitably some users will encounter errors. It’s important we make these as painless and easy to fix as possible.

Always validate the form when it’s submitted.
- This gives users feedback when they expect it.
Always be tolerant of mistakes like extra spaces, dashes and slashes.
- Do the hard work so users don’t have to.
Always display a list of errors at the top of the
- Use ErrorSummaryNotification.
Always use concise, plain language for error messages.
- Avoid pleasantries like ‘please’.
Avoid disabling buttons except while a form is submitting.
- They create a poor user experience and exclude many people with disabilities (opens in new window) .
Never use HTML default validation.
- The messages provided by the browser are not always helpful (opens in new window) .
- Add novalidate to the form.
Never validate as the user types.
- It interrupts the user when they are trying to answer the question (opens in new window) .