Overview

Buttons express what action will occur when the user clicks or touches it. Buttons are used to initialize an action, either in the background or foreground of an experience.

Usage

Use when

  • Affording interaction to key behaviors and features.
  • Confirming or submitting information entered into a form.
  • Cancelling and action.
  • Resetting a form or dataset.
  • Closing a container or section.
  • Opening a menu.
  • Moving forward or backward through a wizard-type workflow.
  • Creating an object within a group.
  • Applying a non-critical action to a dataset.

Don’t use when

  • Displaying a collection of links to sections. Use links instead.
  • Linking to an external site. Use links instead.
  • An action is less important. Consider using a link instead.
  • Presenting the user with one or more high or medium-high actions specific to a task.

Types

There are two button progressions you can choose from: structural and color progression. The choice should be based on the particular needs of the product’s intended usage, aesthetic, and/or target user’s needs. Use only one button progression in a single product. Ancillary button types can be used in either progression.

Structural Progression

Example Emphasis When to use
High Use to draw attention to the primary action on a screen. There should be only one Primary Button on a page at a time. Not all screens require a Primary Button.
Medium Use for secondary actions on a screen. Outline-style buttons work well on colored, dark, or image backgrounds. Consider how the style of an outline button might better suit the page.
Medium Used for secondary actions to establish additional visual hierarchy.
Low Use in complex applications or smaller containers that require a minimal impact from button color on the interface. They need to be offset from the rest of the UI to promote visual prominence.

Color Progression

Example Emphasis When to use
High Use to draw attention to the primary action on a screen. There should be only one Primary Button on a page at a time. Not all screens require a Primary Button.
Medium Use for secondary actions on a screen. These Buttons can be used on most pages without constrictions. They appear most often in high volume use cases like Tables, or in an Action Bar. Consider using an outline button on gray backgrounds.
Medium Used for secondary actions to establish additional visual hierarchy or to use a secondary button that provides less emphasis.
Low Use in complex applications or smaller containers that require a minimal impact from button color on the interface. They need to be offset from the rest of the UI to promote visual prominence.

Ancillary Buttons

Type Example Emphasis When to use
Icon Only
Medium Primary use is in-line or in “Button Groups.”
Danger High Danger buttons have a different visual style to inform users of potentially destructive actions they are about to take. If using the danger button as a standalone, we recommend styling it as a secondary button. Within a set, the danger button should be styled as a primary button.

Note: A yellow button in the Trimble brand color can be used only in special use cases..

Specifications

  • All buttons should be interactive and perform an action.
  • They should be discoverable, easy to identify, and specific.
  • Always have a text label within the button container. Icons are optional.
  • Make buttons look and feel clickable.
  • If using multiple buttons, label them distinctly.
  • The size of the buttons should be used in proportion to the context and content around it.
Example Height Use Case
Small 24px Tables
Default 32px Action Bars
Large 48px Modals

Behaviors

All buttons (including icon buttons) should have the following states:

  • Default
  • Hover
  • Pressed
  • Disabled

Structural Progression States

State Primary
Default
Hover
Pressed
Disabled

Color Progression States

State Primary
Default
Hover
Pressed
Disabled

Auxiliary Button States

State Icon Only Danger
Default
Hover
Pressed
Disabled

Icon button state colors may vary based on product. Always make sure the colors of all states (except for disabled) meet color contrast accessibility standards .

Editorial

  • All buttons in the Modus Design System employ sentence case.
  • Label a button with a verb, like “Copy”, or verb-phrase, like “Copy document.”
  • Strive for short button labels that clearly describe an action.
  • Try to limit button labels to three words or less. Using one or two words, if possible, is ideal.
  • When writing buttons, you can remove most prepositions and articles (e.g. a, an, the).
  • If a question is asked in a modal, use button labels that match the question. Keep in mind the following guidelines as well:
    • Don’t use OK/Cancel to answer yes or no questions.
    • Make sure you keep “your” and “my” consistent.
    • Avoid saying “click” when referring to buttons (and other UI elements).

Accessibility

  • Buttons have role of button. Using a native HTML button or input type="submit" element is a better choice than creating a custom ARIA button.
  • Buttons should have accessible labels. By default, the accessible name is computed from any text content inside the button element.
  • A button should be triggered by pressing “Spacebar,” “Enter,” or “Return.”
  • Make sure the mouse cursor is an arrow pointer, not a text selector or a hand icon.
  • Disabled buttons should have aria-disabled set to true.
  • When placing a button on a color other than standard background colors (Gray Light or White), make sure the colors of all states (except for disabled) still meet color contrast accessibility standards .
What's Changed
Date Version Notes Contributors
04/07/2020 1.0.1 Light gray button added to the color progression. E. Bohn, E. Gunther, L. Cook
11/23/2020 1.0.0 Two progressions identified for clarity of use. Custom focus states added for accessibility. E. Bohn, E. Gunther, L. Cook, L. Kause, S. Williams