Forms
There are 2 main types of forms, those found on setup pages and those on settings pages. Both are used to collect user data via form elements like text, or select inputs. Forms on setup pages are used to setup accounts, processes, or features, and can have a sticky footer, whereas a settings page form allows the user to alter data they defined previously on a setup page.
Setup page forms
Setup page forms can either be contained on a single page or be broken out into multiple pages using a stepper. Use a stepper if the sequence of the form steps are known. Do not use a stepper for settings page forms.
If the setup form starts with a text input, have that input auto-focus on-load. Do not use this pattern for settings page forms.
Settings page forms
Settings page forms can either live on a single page, or if long with many sections (3+ sections with 3+ inputs each), can be broken up into several different pages. For these types of forms, do not use a sticky footer, and if needed, place the back button on the top left of the page.
When possible, help the user by pre-filling the form.
UI design & Label placement
Consider the user’s mental model when designing your form. Usually, if it’s a setup form, the user will progress linearly from one input to the next. In this case, having labels above the input is best. On a settings page, if the user is scanning the form for a specific line item, consider placing the labels on the left of the input instead. More information on label placement.
Single column forms perform better than multi-column forms
Exceptions to this rule are short and/or logically related fields such as City, State, and Zip Code. Learn more.
Progressive disclosure
You can decrease the cognitive load of your setup form by only surfacing the immediate inputs the user needs to complete before surfacing other secondary inputs. Learn more about progressive disclosure.
Form modals
Forms in modals allow the user to complete simple tasks (usually less than 4 inputs) while maintaining the context of the page they’re on. Forms with steppers should not be in modals.
Divide fields into semantic groups, and when possible try to group sections into cards.
Expandable cards in setup forms can be used to display advanced or secondary parts of your form that are not essential to the form’s completion. Don’t make all your sections in setup forms collapsible.
Use expandable cards on settings pages, that have many sections, to improve scan-ability.
Avoid making sections with only one input expandable/collapsible. Consider having the first card open by default.
When a card is closed, its chevron points opposite to the direction the card opens. When open, the chevron points towards the opened content. Don’t use carets for this pattern. Carets are affordances for menu and select input dropdowns.
Form buttons
Buttons are sorted by importance from right to left, with the primary button on the right.
Form confirmation buttons should remain disabled until the form can be submitted or the user can move on to the next step. Never use a reset button.
Only surface a back button on a setup form that uses a stepper. If needed, place the back button on the bottom left of the sticky footer after the user has completed the first step.
Multi-page settings forms (with no sticky footer) can also have a back button. In this scenario, place the back button on the top left.
Sticky footer
Learn more about forms' sticky footers here.
Autosave
When possible, design settings page form inputs to validate inline and autosave (when not making destructive changes). When groups of form elements need to be completed in a setting form, consider placing the buttons inside the appropriate card. Avoid having global buttons on a settings page form.
Preventing errors
Use field length as an affordance for the type of entry the user needs to input.
Whenever possible, surface input constraints to help users complete the form.
Make sure to surface a confirmation modal if the change is destructive or cannot be undone.
Whenever possible use the appropriate input type for the data you’re collecting. Some of these inputs will have custom validation patterns.
Form validation & error handling
Try not to let the user reach the end of the form to inform them that something is wrong. LeafyGreen inline validation has been developed such that, on valid (“clean”) fields, inline validation will occur when a user leaves the field; on invalid (“dirty”) fields, inline validation will occur while a user is typing in a field.
There are 3 types of validation you can surface: success, error, or loading. All types can and should be used inline. (For success you can optionally add a checkmark to the input, if you want to provide a visual affordance for a complex entry in a field, like a password.)
Sometimes inline validation is not possible when surfacing certain errors: In those instances, consider using a global error banner to provide an overview of the error if needed. Global error banners should be placed within the sticky footer of a form, to the left of the buttons. When a sticky footer is not applicable, place the error banner above the CTA buttons.
Language
Use positive language, and/or provide a suggestion. Don’t make users feel like they are at fault. Be clear in your error messages. Specify where the error is occurring and what needs to be done to fix it. (Exceptions to this rule exist, like login forms where credential security takes precedence.)
Required & optional fields
Try to minimize the use of optional fields. In setup page forms, required fields should be marked as required using \*. Optionally, label optional fields as optional. Do not use required or optional markers for settings page forms.
Consider the device type the form will be completed on
Use the appropriate mobile native pattern for each form input.
