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 LayoutCopy URL

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 GuidelinesCopy URL

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 StructureCopy URL

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 AffordanceCopy URL

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

Input FieldCopy URL

Input fields allow users to enter and interact with data. Often used with form layout, but can exist outside of a standard form.

Common input field anatomy includes:

  • Label: Description of text field.
  • Type: Type datum field to render e.g., “text, number, password, email.”
  • Help Text: Context to what the user should do with text field.
  • Placeholder Text: Example text within the text field.
  • Input Field: Contain to accept text, numbers, or combination of both.

Less common input field anatomy includes:

  • Character Count: Informs how many characters can be used in input field.
  • Drop Down: Options to modify what information the input field accepts.

ExamplesCopy URL

Default Input Field Anatomy

Default Input Field Anatomy

UsageCopy URL

Best Practices

  • Input fields should:
    • Use a label that is meaningful, clear, and concise.
    • Use basic help text, do not hide it.
    • Use placeholder text that’s formatted as an example, not as a label.
    • Use sentence case and avoid all uppercase.
    • Use the proper input length as an affordance to how much content can be entered.
    • Use inline validation.
    • Use browser default for focus state.
    • Use the proper input type in HTML based on the data being collected. e.g., type='email' for email, type='number' for numeric values, type='text' for general text.

Optional text should:

  • Be after label
  • Be lower case
  • Be contained in parenthesis

Optional input field

Help Text example

Help text example

Placeholder Text

Placeholder text appears inside of an input field. This text can serve as a hint or an example of what the user could enter. When a user enters data into an input field the placeholder text should disappear. Placeholder text is not accessible to all users and should not be used to provide instruction or be required to use an input field.

Placeholder text should:

  • Be used only for supplemental information
  • Be written as examples, not instructions
  • Be short and concise
  • Be written in plain language

Placeholder text

Input

The input allows users to enter text, numbers, or a combination of both as information to submit.

Inputs should:

  • Be the proper length for the amount of content that can be entered
  • Be able to use states, like active, focus, and disabled
  • Be a consistent vertical height, e.g. 40px

Input field length

Character Count

Character count is persistent text within the input field that shows how many characters can be used. In addition to the length of the input field, this provides users with additional context on how much content can be entered into a field.

Character count should:

  • Be the max number of characters
  • Be fixed on the right of a field
  • Be dynamic and countdown as a user enters characters

Character count

Validation and Errors

Validation and errors help the user understand what is incorrect in an input field. Validation should happen after the user fills out the field.

  • Be clear and explain what is incorrect and how to fix it
  • Be short and concise, single sentence
  • Be sentence case
  • Be written in plain language
  • Be obvious, with use of color or iconography

Input error

LabelCopy URL

Labels are used to describe each element within a form. All form elements should have a label.

Label example

Best PracticesCopy URL

Labels should:

  • Be meaningful, clear, and concise
  • Be short (i.e. 1-4 words)
  • Be sentence case
  • Be written in plain language
  • Assume all fields are required, unless designated as “(optional)”
  • Always use the <label> or similar component over arbitrary HTML
  • Use a for attribute in the <label> and map to associated form field

Style:

  • Semi-bold (600 weight)
  • Neutral 800
  • Font Size 200
  • Space Size 200 after label

CheckboxCopy URL

OverviewCopy URL

Checkboxes provide users with a range of options for a given statement where the user may select any number of choices, including zero, one or multiple. They may also allow users to give consent when paired with agreements, like terms of service.

StyleCopy URL

  • Border Radius 500
  • Border Weight 500

StatesCopy URL

UncheckedCheckedIndeterminate
Default
  • Background Transparent
  • Border Color: Neutral 300
  • Checkmark hidden
  • Background Color: Neutral 600
  • Border none
  • Background Color: Neutral 600
  • Border none
HoverCheckmark visibleBackground Color: Neutral 700Background Color: Neutral 700
FocusFocus states should default to the browser’s native treatment.
Disabled
  • Opacity 40%
  • Cursor not-allowed

Checkbox Anatomy

Checkbox anatomy

Checkbox Layout

Checkbox layout

GuidelinesCopy URL

  • Use positive clear language so it’s clear what happens when a user clicks on the checkbox.
  • Avoid negations such as “Don’t send me more emails”, which would mean that the user would have to check the box in order for something not to happen.
  • The default view for checkboxes has no option selected.
  • Checkbox options should be listed according to a logical order (alphabetical, numerical, time-based, etc).

Radio ButtonsCopy URL

OverviewCopy URL

Radio buttons allow users to make a single selection among a group of options.

StyleCopy URL

  • Border Radius 50% (a circle)
  • Border Weight 500

StatesCopy URL

UncheckedChecked
Default
  • Background Transparent
  • Border Color: Neutral 300
  • Dot hidden
  • Background Color: Neutral 600
  • Border none
HoverDot visibleBackground Color: Neutral 700
FocusFocus states should default to the browser’s native treatment.
Disabled
  • Opacity 40%
  • Cursor not-allowed

Radio AnatomyCopy URL

Radio anatomy

Radio LayoutCopy URL

Radio layout

GuidelinesCopy URL

  • List options in a rational order that makes logical sense (alphabetically, numerically, time-based, etc.)
  • Most likely to least likely to be selected
  • Include at least two or more choices
  • Include mutually exclusive options—this means that each option must be independent from every other option in the list
  • Have no option selected in the default view

Drop-downs allow users to select an option from a menu of pre-defined choices. A drop-down is best utilized when there are more than four choices.

  • If you want a searchable drop-down, then reference Single-Select [still in progess].
  • If you want a drop-down that allows multiple selections, then reference a Multi-Select.

FieldCopy URL

Field

ListCopy URL

List

Best PracticesCopy URL

  • Drop-downs should:
    • Contain four or more items.
    • Limit each item to a single line of succinct text, unless using title within list item.
    • If using a title, limit title to single line and text to single line.
    • Use menus that are sorted in a logical order.
    • Use a default selection, if possible.
    • Use a placeholder option, such as “Select…” if no default is available.
    • Use avatars or icons, if appropriate to provide additional context.
    • Use sub-menus to guide the user to the appropriate action.

Field

A drop-down field follows the same rules as an input field, in regards to labels and help text. Drop-down fields also have a similar active, focus, disabled, and error states.

Example with help text

Example with help text

Placeholder Text

A drop-down field should have a default option selected. If no logical default exists, the field should have placeholder text.

Placeholder text should:

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

Example

Dropdown with placeholder text

Menu

A drop-down menu appears after the user clicks on the drop-down field. This menu will contain drop-down menu items.

Drop-down menu should:

  • Be at least 4 or more items in length
  • Be sorted in a logical order, i.e. alphabetically or chronologically
  • Be properly grouped with titles, if necessary
  • Be sorted into sub-menus, if necessary

Example

Drop down example

Drop down example

Menu Item

A menu item appears within the menu. Menu items may consist of text, text plus avatar, or text plus icon.

List items should:

  • Be limited to a single line of succinct text, unless using title and text
  • Be limited to single line title and text, if using a title
  • Be able to use states, like active, focus, selected, and disabled
  • Be able to use avatars or icons

Example

Drop down list

Drop down list with avatars

Drop down list with titles and text

Grouping

List items can be grouped within a menu. The use of titles within the list can separate grouped content.

Groups should:

  • Be organized by title (that’s not selectable) and describes the content in the sub-group
  • Be visually separated from other sub-groups

Example

Drop down list with titles and text

Icon Drop-Down

An icon drop-down is a style variation on the drop-down. This drop-down is initiated from an icon button. Use this style when full text or input is not an option, due to aesthetics or space limitations.

Icon drop-downs should:

  • Be initiated from an icon that relates to the menu content, e.g. file icon = file types
  • Be smart, e.g. if the menu is too close to the top of the page, the menu will open downward
  • Be positionable, e.g. the icon can be positioned (in relation to the menu):
    • Top: Left, Center, Right
    • Bottom: Left, Center, Right
    • Left: Top, Center, Bottom
    • Right: Top, Center, Bottom

Example

Drop down positioning

Inline Drop-down

An inline drop-down is a style variation on the drop-down. Inline drop-down fields are text only, omitting the input box containing the text. These are used in areas where visual weight needs to be limited or multiple drop-downs close to one another.

Example

Inline drop down

Multi-SelectCopy URL

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 PracticesCopy URL

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 FieldsCopy URL

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 listCopy URL

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 ElementsCopy URL

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

Example:

Label search elements

Filter List ElementsCopy URL

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

TogglesCopy URL

Toggles are an interactive element that allows users to quickly enable or disable a setting. Toggles are used to simply turn something on or off. Don’t use a toggle to change state on a page (i.e. Tabs). This should always be used to alter settings, and never used to trigger an action. Settings altered with a Toggle should save immediately after toggling, and that setting should persist automatically. If the metaphor of having an always-present light switch to represent this setting makes sense, then use a Toggle.

ExamplesCopy URL

Current Sprout Toggle AnatomyCurrent Bambu Toggle Anatomy
Sprout toggle anatomyBambu toggle anatomy

When to useCopy URL

  • Toggles are used for settings to enable or disable things
    • If the setting can only be off/on

How to useCopy URL

  • Toggle states are saved immediately on click
    • Like a light switch, you don’t flip it, then submit it. The change takes effect right when you click.
  • Toggle states are persistent
    • A change to a toggle persists throughout all sessions until user flips the toggle again. (Again, like a light switch)

PresentationCopy URL

  • All Checkboxes must always have an associated label
    • Label must be written as to describe the on state of the toggle.
      • i.e. “Email Notification Enabled”
    • Avoid using negations such as “Notifications Off”, which would mean the user would have to turn the toggle on to turn the setting off.
    • Detailed descriptions of the Toggle Setting should be placed directly beneath the toggle.

State AffordancesCopy URL

  • Do not rely on visuals (color / toggle location) to indicate the state (on or off)
    • State affordances describe current state, not state after click
      • On / ✓ / I - if these are shown, that means it is currently in the on state
      • Off / ✗ / O - if these are shown, that means it is currently in off state

AccessibilityCopy URL

General GuidelinesCopy URL

  • Autofocus the first field by default. This allows users to tab through elements in the form in a logical way.

CheckboxesCopy URL

  • Semantic Checkbox

    • Semantic HTML should always be used when possible.

      <input type='checkbox' role="checkbox" />

    • If semantic HTML is not an option, use the ARIA-role for checkbox

      • If you need the “indeterminant” state, that is only available with role="checkbox"
    • If using the “checkbox” role, developer is required to keep track of selected state using aria-checked attribute aria-checked is “true” if checkbox is selected aria-checked is “false” if checkbox is not selected aria-checked is “mixed” if checkbox is indeterminant

  • Associated Label

    • All checkboxes must have an associated label
    <span role="checkbox" aria-checked="false" tabindex="0" id="chk1"></span>
    <label for="chk1">Remember my preferences</label>
  • Since a checkbox is an interactive control it must be focusable and keyboard accessible.

    • If the role is applied to a non-focusable element, the tabindex attribute will have to be used to change this.
  • The expected keyboard shortcut for activating a checkbox is the Space key.

Radio ButtonsCopy URL

  • Semantic HTML should always be used when possible. <input type="radio" />

  • If semantic HTML is not an option, use the ARIA-role for radio button wrapped in a radio group role.

    <div role="radiogroup" aria-labelledby="pizza-crust">
    <h3 id="pizza-crust">Pizza Crust</h3>
    <div role="radio" aria-checked="true" tabindex="0">
    Regular crust
    </div>
    <div role="radio" aria-checked="false" tabindex="-1">
    Deep dish
    </div>
    <div role="radio" aria-checked="false" tabindex="-1">
    Thin crust
    </div>
    </div>

    If using the “radio” role, the developer is required to keep track of selected state using aria-checked attribute

    • aria-checked is “true” if radio button is selected
    • aria-checked is “false” if radio button is not selected
  • All radio buttons must have an associated label

    <span role="radio" aria-checked="false" tabindex="0" id="chk1"></span>
    <label for="chk1">Remember my preferences</label>
  • Since a radio button is an interactive control it must be focusable and keyboard accessible.

  • If the role is applied to a non-focusable element, the tabindex attribute will have to be used to change this.

  • The expected keyboard shortcut for activating a radio button is focusing the element with the arrow keys.

LabelsCopy URL

  • Autofocus the first text field in a form by default
  • Labels are announced to screen reader on focus
  • Help text is read when using assistive technology
  • Use sentence case, avoid all uppercase
  • Text labels should have high contrast and be a legible size
  • Use 40px height, for large enough hit or tap area
  • Use keyboard navigation

TogglesCopy URL

  • Semantic Markup
    • There is not a native HTML Toggle Switch. Instead, use the switch ARIA-role
      <button role='switch' aria-checked='false'>
    • Similar to checkboxes, the aria-checked attributes help control the on/off state of the switch. The developer is required to keep track of this state.
    • Unlike checkboxes, however, buttons with role='switch' cannot have the value of "mixed", as switches and only be true or false.
  • Associated Label
    • All Toggles must have an associated label
HTML
<button role="switch" aria-checked="true" tabindex="0" id="speakerPower" class="switch"> <span>off</span> <span>on</span></button> <label for="speakerPower" class="switch">Speaker Active</label>
JavaScript
document.querySelectorAll(".switch").forEach(function(theSwitch) {,theSwitch.addEventListener("click", handleClickEvent, false); });,function handleClickEvent(evt) {,let el = evt.target;,if (el.getAttribute("aria-checked") == "true") {,el.setAttribute("aria-checked", "false");,} else {,el.setAttribute("aria-checked", "true");,} }
  • State description
    • In order to accommodate as many needs as possible, you must follow these guidelines for indicating the state (on/off) to the user
      1. Do not rely on Iconography or Color alone
      2. The ”✓” does not translate to ON in all cultures
      3. I / O symbols are fairly universal, but not 100% (Apple trusts I/O as the indicator)
      4. Ideally, we will use plain text (i.e. On, Off) to explicitly state the current value of the Toggle
      5. In order to best accommodate localizations, these text labels should appear to the right of the toggle, and not inside of the toggle.

Do’s and Don’tsCopy URL

  • 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 InspirationCopy URL