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.
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.
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.
The Stack component should be used to control the vertical spacing between form fields.
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 an example of this in the Card component documentation.
- 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.
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.
- 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.
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) .
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
- Always use concise, plain language for error messages.
- Avoid pleasantries like ‘please’.
- Avoid disabling buttons except while a form is submitting.
- 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.
- Form design by Adam Silver (opens in new window)
- GOV.UK form structure (opens in new window)
- Disabled buttons suck by Hampus Sethfors (opens in new window)
- Form design: handling optional fields by Adam Silver (opens in new window)
- Why you shouldn’t include disabled interaction elements in your design system by Chris Atherton (opens in new window)
- Considered harmful: do not use disabled or readonly input attributes as default by Nick George (opens in new window)
- A few lessons in form design by Shankar (opens in new window)
- Why You Shouldn’t Gray Out Disabled Buttons by Anthony at UX movement (opens in new window)