Patterns

Forms

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 Layout

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

Form columns

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

Section title

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

Input fields

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

Help text

  • 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

Checkboxes

  • 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
    • Use primary button type for main action and a de-emphasized style such as the secondaryinverse button or link style for secondary action.

Information Structure

Section titles:

  • 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.”

CTAs

  • 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-Select

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.

Examples

Drop down with multi select

Best Practices

Multi-selects should:

  • 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

A multi-select input field follows the same rules as a drop-down and input field with the exception that it allows for multiple inputs such as tokens.

Placeholders should:

  • Be set to a default value, if possible
  • Be “Select…” or a variation, e.g. “Select a profile…”

Placeholder examples

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.

Examples

Multi select from list

Grouping

List items can be grouped within a multi-select drop-down menu. The use of titles within the list can separate grouped content.

Groups should:

  • Be organized by title and describes the content in the sub-group
  • Be visually separated from other sub-groups

Example:

Multi select grouping

Label Search Elements

The following is an example of labels in a message tag component.

Example:

Label search elements

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
  • Specific

Example:

Filtered list elements

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.

Example:

Token usage in select

Errors

Error states provide immediate feedback to the user.

Error feedback:

  • 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

Example

Multi select errors

Do’s and Don’ts

  • DO:Correct Form Layout Usage Group related information in a logical sequence.
  • DON’T:Incorrect Form Layout Usage Combine unrelated sections in large or complex forms.
  • DO:Correct Form Layout Usage Group labels closely with their text fields.
  • DON’T:Incorrect Form Layout Usage
  • DO:Correct Form Layout Usage Use labels to describe form fields.
  • DON’T:Incorrect Form Layout Usage Use placeholder text as an alternative to a label.
  • DO:Correct Form Layout UsageExpose basic helper text wherever possible. For complex helper text, consider placing it next to the input during its focused state.
  • DON’T:Incorrect Form Layout UsageUse tool tips for helper / requirement text.
  • DO:Correct Form Layout UsageUse inline validation after the user fills out the field.
  • DON’T:Incorrect Form Layout UsageDon’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:Sentence Case labelShow error message below form field, in subtle format.
  • DON’T:All Caps labelArbitrarily style or display inline validation.
  • DO:Correct Inline Error UsageTailor the length of form fields based on the content.
  • DON’T:Incorrect Inline Error Usage

Additional Resources and Inspiration