Overview
When to use
Forms should be used when you need your user to provide data or configure options. Forms are one of the most common types of interactions. Overall forms are often the final step in the users journey and plays a huge role in whether the user completes their goal or not.
Forms are often used for:
- Signing up
- Login in
- Checkout when purchasing a product
- Complete a profile
- Consent and marketing permission
- Requesting to be contacted
- Completing a survey or a check
How to use
A user should be able to complete a form without any confusion and with as little fuss as possible. In order to reach this goal, there are some best practices you should keep in mind:
Ensure a clear information hierarchy
In order for forms to be easy to scan and complete, it’s critical that a clear information hierarchy is used throughout the forms. Consistent section headers and spacing between form sections and elements, should make it easy to interpret the relationship between groups of information.
Make the form easy and predictable
Forms should be organised in a logical way that supports the user’s current workflow. This is done by only including the parts of a form that the user expects. If you have to ask for something that they might not have expected, consider including a ‘why is this information asked of you’.
Furthermore, the form should be as easy as possible to complete. Therefore, allow users to stay with a single interaction method for as long as possible (i.e. do not make users shift from keyboard to mouse numerous times in a single form).
Focus on the core task
A form can easily be overwhelming. Try to provide the user with one task at a time, so it is easier for them to keep focus. This sometimes means dividing the form into steps, instead of forcing all tasks into one step or view.
Keep it short and avoid optional fields
Remove fields that collect information that can either be a) derived in some other way, b) collected more conveniently at a later date, or c) simply omitted. This means that optional fields should be avoided.
What to use
A form can consist of different components. The following overview provides a list of the different components a form can be comprised of. When you have to decide what components to use, this overview can hopefully guide you in the right direction
|
Control |
Usage |
Context |
|---|---|---|
|
Text input |
To capture one or several words in one line. |
Names, phone numbers, parts of addresses. |
|
Text area |
To capture several lines of text. |
Feedback, comments, messages. |
|
Password |
To collect private data by hiding the characters. |
Passwords, Social Security Numbers (SSN), PINs, credit card information. |
|
Number input |
To enter a numeric value and incrementally increase or decrease the value. |
Order quantities. |
|
Dropdown |
To select a value from a customisable list of options. |
More than 4 options, less than 15. |
|
Select |
To display a list of options using the browser’s native select menu. |
Language. |
|
Multiselect |
To select multiple items from a longer list. |
Languages you speak, filtering. |
|
File input |
To upload content, one or multiple files at a time. |
Upload images, receipts, documents etc. |
|
Combobox |
To filter a list when selecting an option. A mix between a dropdown and a text input. |
More than 15 options. E.g. Country selection. |
|
Checkbox |
To support multiple choice scenarios. |
Accept terms and conditions, choose multiple scenarios that the user resonates with. |
|
Radio button |
To provide exclusive choices where only one selection from the group is allowed. |
Yes / no / don’t know. |
|
Toggle |
To choose one of two or more binary options. |
Changing user settings; On/off; Show/hide. |
|
Date picker |
To input/select a single localised date or a date range from a calendar. |
Scheduling trips, meetings, and events. |
|
Slider |
To select one number from a numerical range. |
Percentages, volume, timelines, data visualisation. |
Designing forms
Anatomy
A form consists of the elements presented in the visualisation below. The purpose of the visualisation is to showcase the anatomy of a form.
- Title
- Section
- Labels
- Input fields
- Helper text
- Buttons
Title
A form title should clearly inform the user of the primary purpose of the form, or the step of the form, that the user is currently on.
Sections
Use sections to group form field in a logical way. Done right, this helps users skim the contents of the form faster. Sometimes it even makes sense to assign the different sections their own step. This is of course a fine balance. As a rule of thumb a step should contain a maximum of 5-9 fields.
Pros of Multi-Step Forms:
- Reduces cognitive overload, by breaking down complex flow
- Lowers drop-off as users aren’t put off by endless fields upfront
- Increases Accessibility. Multi-step forms improve experiences for users requiring assistive devices with potential motor, visual og learning needs.
Labels
Form labels are descriptive text elements accompanying form fields. Their main purpose is to provide context and meaning to the form input field and to ensure that users understand what information they are required to input into the form field.
Using labels offers several accessibility advantages e.g. for users with disabilities. Screen readers can easily associate form labels with form fields, enabling visually impaired users to understand the purpose of each field. Form labels also help to improve the user experience by making forms more intuitive and user-friendly. Clear and concise labels reduce confusion and minimize errors, resulting in a better overall user experience.
Helper text
Helper text is an optional assistive information to help guide the user to correctly complete a field. It appears as text below form fields and is the preferred method of assisting users because it is always visible for the user to reference without additional effort.
- Helper text should always be available when an input is focused.
- It is often used to explain a required data format.
-
Use sentence-style capitalisation, and in most cases, write the text as full sentences with punctuation
Buttons and button alignment
Use a primary button for the main action, a secondary button for secondary actions like Cancel or Discard.
|
Alignment |
Use case |
|---|---|
|
Left aligned |
In-page forms (single page and non-dialog) |
|
Right aligned |
Multistep forms/wizards where the primary action implies a navigation step forward |
|
Full width |
Forms in modals and drawers/side panels |
Single vs. multi-column
Single column forms have proven to be less prone to misinterpretations and should be the default choice. Related fields, however, are sometimes positioned inline for logical and space-optimizing reasons, while keeping an overall single column approach. Use common sense to determine when this is an appropriate solution - e.g. First name/last name, or city/state/zip-code.
In certain situations on larger screens it can be appropriate to use a two-column layout.
Content guidelines
Required vs. optional
Make sure all the required fields are essential to allow the user to progress. Too often, the required fields are only required in the sense that someone on the business side wants the field, rather than it being needed.
- By default, text inputs are required unless marked with “optional”.
- The pattern can be reversed using “required” on the required fields instead, but this should be an exception.
- Limit the number of optional fields to 2-3 for a single form.
- Be consistent with a chosen pattern throughout a product or at minimum between similar types of forms within a product.
- Don’t mix the “required” and “optional” patterns to show both at the same time.
If the majority of the field are required, mark only the optional label with (optional).
If the majority of the fields are optional, mark only the required field labels with (required). This should be an exception only though, as you should not include fields that are not needed.
Placeholder text
- Avoid the use of placeholders in general due to their problematic nature - https://www.nngroup.com/articles/form-design-placeholders/
- Placeholder text provides hints or examples of what to enter.
- Placeholder text disappears after the user begins entering data into the input and should not contain crucial information.
- Placeholder text does not serve as a sufficient means of meeting accessibility requirements for labels. To meet accessibility requirements, placeholder text should be used in conjunction with a label or aria-labelled by attribute.
Labels are in most cases self explanatory. If you need to further elaborate on limitations of or details about a field, consider enabling the helper text.
Don’t repeat label texts as placeholders! Leave the field empty unless something is not explained by either the label or a helper text.
Behaviour
Errors
Immediate and efficient error messages can help users to understand the issue and to find solutions. Begin by notifying users about what has happened, followed by guidance for next steps or potential solutions. Always present error states on the form, and use inline errors whenever possible.
Consider the type of field and its context when deciding when to display the error message. For example, allow the user to finish typing their email before validating the format (it’s annoying to be informed about a missing “@” when you haven’t had a chance to type it yet). In other cases, there can be fields where users benefit from finding out about an error sooner rather than later – like typing a letter when only numbers are allowed.
Inline errors
Showing errors as and where they happen make them easier to identify and with helpful messages, users can proceed with confidence.
Group errors
Grouped radio buttons and checkboxes should display a single error for the entire group.
Section errors
In cases where an entire section has been omitted by the user, it’s better to display an alert above that section as inline errors on all elements can overwhelm the user. Always make sure the alert is visible when it appears so there’s a implicit connection between the action that triggered the alert and the alert itself, by scrolling the alert into view if the form is too long i.e on mobile.
Validation
Forms can validate errors and alerts dynamically (client-side) or on submit (server-side).
Client-side validation
Validating fields as soon as they lose focus will help to easily identify the elements that need to be corrected. The error text should be as informative as possible when describing the issue.
Server-side validation
Sometimes validation can only happen after the user has submitted the form. A general alert should inform the user of what happened and how to continue. If possible, highlighting the field that was the cause of error can be extra helpful.
Error message composition
- Explain what caused the error
- Provide assurance to the user
- Explain why the error occured
- Help them fix the problem
- Give the user a way out
Processing states
User interactions should always be reflected in the interface. If it’s going to take a while to submit or process a form, communicate this to the user with a progress indicator (e.g. spinner).
Primary button spinner
Displaying spinners on primary buttons is a common practice to indicate important active actions in a user interface. Primary buttons are visually prominent, conveying the significance of the action. Users expect quick feedback when clicking primary buttons, and the spinner shows that a process is underway. It helps manage user expectations, prevents duplicate actions, maintains design consistency, and aids in providing a predictable and user-friendly experience.
Full page spinner
Full-page spinners serve the purpose of providing immediate feedback during lengthy operations, such as data loading or background processes, where users would otherwise experience uncertainty or impatience. They are crucial in scenarios where users risk engaging in conflicting actions that might disrupt ongoing operations, promoting a smooth and error-free user experience.
It's important to use full-page spinners judiciously. They should be displayed only when necessary, and users should receive informative messages about the operation's progress. Overuse of spinners can lead to frustration, so it's crucial to strike a balance between providing feedback and minimizing user wait times. Additionally, always consider the accessibility of full-page spinners to ensure that all users, including those with disabilities, have a positive experience.
Focus states
Some people use keyboards or other devices to navigate through a page by jumping from one interactive element to the next. Focus states let users know which element they’re currently on and is ready to be interacted with.
Buttons
When to disable buttons
- Long forms Disabling buttons in forms, especially in longer forms, can cause frustration since it can be difficult for users to find what they missed. Therefore only use disabled buttons if you give proper guidance on why the button is disabled and how to proceed. Make sure always to provide a way out.
- Short forms If a form is very short and all contents of the form can be viewed without scrolling (keep mobile scenarios in mind), buttons may be disabled until all requirements are met. This is especially true for forms that only require 1–2 inputs, or where a user must acknowledge via a checkbox that they understand the consequences of submitting a form.
Articles
- Website Forms Usability: Top 10 Recommendations - Nielsen/Norman Group
- Placeholders in Form Fields Are Harmful - Nielsen/Norman Group