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.

form-guidelines-1@3x.png

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.

form-guidelines-2@3x.png

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.

form-guidelines-3@3x.png

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.

form-guidelines-4@3x.png

When possible, help the user by pre-filling the form.

form-guidelines-5@3x.png

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.

form-guidelines-6@3x.png

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.

form-guidelines-7@3x.png

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-guidelines-8@3x.png

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.

form-guidelines-9@3x.png

Divide fields into semantic groups, and when possible try to group sections into cards.

form-guidelines-10@3x.png

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.

form-guidelines-11@3x.png

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.

form-guidelines-12@3x.png

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-guidelines-13@3x.png

Form buttons

Buttons are sorted by importance from right to left, with the primary button on the right.

form-guidelines-14@3x.png

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.

form-guidelines-15@3x.png

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.

form-guidelines-16@3x.png

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.

form-guidelines-18@3x.png

Preventing errors

Use field length as an affordance for the type of entry the user needs to input.

form-guidelines-19@3x.png

Whenever possible, surface input constraints to help users complete the form.

form-guidelines-20@3x.png

Make sure to surface a confirmation modal if the change is destructive or cannot be undone.

form-guidelines-21@3x.png

Whenever possible use the appropriate input type for the data you’re collecting. Some of these inputs will have custom validation patterns.

form-guidelines-22@3x.png

Form validation & error handling

When user text input is required, aim for inline validation with real-time feedback whenever possible.

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.

form-guidelines-23@3x.png

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.)

form-guidelines-24@3x.png

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.

form-guidelines-25@3x.png

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.)

form-guidelines-26@3x.png

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.

form-guidelines-27@3x.png

Consider the device type the form will be completed on

Use the appropriate mobile native pattern for each form input.

form-guidelines-28@3x.png