These conventions are intended to provide guidance for both layout and proper usage of various form elements.
Designing an effective form requires consideration for its information hierarchy, sequence of form elements, clarity of labels, affordance, feedback, and accessibility.
Form layouts organize input fields for our users to enter data and configure options. A form layout should be easy to scan, understand and complete.
Form Layout and Usability Guidelines
- Forms should be one column in most cases.
- Multiple columns disrupt a user’s vertical momentum.
- In some cases, however, related fields may be grouped together in a single row.
- Every section of a form should have a section title. See content guidelines below for section titles.
Optional vs. Required Fields
- We only collect the data we need so most input fields within a form should be required. If you ask a user for optional information then ‘Optional’ text should be used to show that it is not required.
- Use text field length as an affordance
- The length of the text field affords the length of the answer expected. Employ this for text fields that have a defined character count like phone numbers, zip codes, etc.
- For mobile, pop the numeric keyboard when numbers are the required input.
- Should be used to provide additional guidance for using a form field
- Should be meaningful and concise
- Should be 1 sentence or less
- Should be sentence case
- Should be written in plain language
- Place checkboxes (and radio buttons) underneath each other to aid in a user’s ability to scan the form.
Primary and secondary buttons
- Most forms will have at least one primary button action unless they are asynchronous form inputs (ghosted or otherwise)
- Asynchronous form inputs should only be used when its necessary to expedite productivity of the user and there are lots of fields
- Otherwise, a form should have a clear action to indicate that the form data is being submitted
primarybutton type for main action and a de-emphasized style such as the
secondaryinversebutton or link style for secondary action.
- Form section titles should be informative, succinct and descriptive.
- Under a form section, if needed, provide a concise description of what the user needs to do with the form or the form section
- i.e. “Billing Address” vs “Address connected to a specific form of payment.”
- Make final CTA button actions clear and descriptive.
- i.e. “Sign Up,” “Log in,” “Request Demo.”
Primary and secondary buttons:
- Differentiate between primary and secondary action text clearly.
- i.e. “Save” vs “Cancel.”
Feedback, Usability, and Affordance
Helper text: Show basic helper text. Do not hide it.
- Expose basic helper text wherever possible.
- For complex helper text, consider placing it next to the input during its focused state.
Inline validation: use inline validation after the user fills out the field.
- Don’t use inline validation while the user is typing —unless it helps them— like in the case of creating a password, username, or message with a character count.
Inline errors: Show the user where the error occurred and provide a reason
Multi-selects allow users to search and select multiple values —names, profiles, tags, etc.—from a list of options. Selected options appear within a text field area, which could also be used as a search box to auto-populate from the database. Multi-selects and single-selects are a subset of drop downs. A single-select only allows you to add a single choice from a text field search. A drop-down allows you a single pre-selected choice.
- If using a title, limit to a single concise line
- If using multiple multi-select, place them in a logical, semantic order
- Use a default select, where possible
- Use a placeholder, such as “Select…” if no default is available
- Use avatars or icons where possible for options
- Avatars and icons should be on the left
- Multi-selects should utilize tokens and search functionality in the text field inputs
- Tokens should use the following pattern:
- Icon/avatar (left) (not required)
- Title of selection (center) (required)
- Close “X” (right) (required)
- Drop down menus should follow drop-down best practices (including logical grouping)
Multi-select Input Fields
- Be set to a default value, if possible
- Be “Select…” or a variation, e.g. “Select a profile…”
Multi-select from list
List view should:
- Select from a list of grouped elements,
- Filter search elements (such as profiles, names, etc).
Select elements displayed as:
- Condensed: The condensed view allows you to show the user that there are more inputs selected that are not displayed.
- Expanded: in the expanded view, users can search, enter a new value and add that new filtered search result to the list of selected elements.
List items can be grouped within a multi-select drop-down menu. The use of titles within the list can separate grouped content.
- Be organized by title and describes the content in the sub-group
- Be visually separated from other sub-groups
Label Search Elements
The following is an example of labels in a message tag component.
Filter List Elements
Filtering of list elements should be clear
Filtered list elements should:
- Be bold to show the term searched
- Match the search term
Token Usage in Select
When tokens go beyond the size of the select input, the input should expand to show the rest of the tokens selected.
Error states provide immediate feedback to the user.
- Appears In the dropdown
- Appears in the input field with a red warning border
- Has a clear title
- Has clear helper descriptions about the error (string error, server error, search query errors, etc.)
- Has icon to describe a warning
Inputs should have:
- Maximum character string sizes
Do’s and Don’ts
- DO: Group related information in a logical sequence.
- DON’T: Combine unrelated sections in large or complex forms.
- DO: Group labels closely with their text fields.
- DO: Use labels to describe form fields.
placeholdertext as an alternative to a label.
- DO: Expose basic helper text wherever possible. For complex helper text, consider placing it next to the input during its focused state.
- DON’T: Use tool tips for helper / requirement text.
- DO: Use inline validation after the user fills out the field.
- DON’T: Don’t use inline validation while the user is typing—unless it helps them—like in the case of creating a password, username, or message with a character count.
- DO: Show error message below form field, in subtle format.
- DON’T: Arbitrarily style or display inline validation.
- DO: Tailor the length of form fields based on the content.