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


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


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


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.


Multi select from list


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


Multi select grouping

Label Search Elements

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


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


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.


Token usage in select


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


Multi select errors

Do’s and Don’ts

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

Additional Resources and Inspiration