Button

Use button to communicate an instantaneous action. Do not use for navigational actions that appear within or directly following a sentence, use the Link component instead.

Button / Size=M (desktop default), Type=Primary, State=Default
Button / Size=M (desktop default), Type=Primary, State=Hover
Button / Size=M (desktop default), Type=Primary, State=Focus
Button / Size=M (desktop default), Type=Primary, State=Pressed
Button / Size=M (desktop default), Type=Primary, State=Disabled
Button / Size=M (desktop default), Type=Primary, State=Loading

 

Content

Requirements

  • Sentence case
  • Ideal: 1-3 words (up to 15 characters)
  • Acceptable: 4-5 words (up to 25 characters)
  • Copy must not wrap

Common structure:

  • Verb + (adjective) + noun --> Copy schedule, Add new employee, Save changes, Add time off
  • Verb --> Add, Save, Download, Copy

 

Best practices

  • Use clear, action driven verbs + specific nouns
  • Describe the action the user is taking or what will happen after clicking that button
  • If the button takes you to a specific modal or page, then the CTA should match/speak with the title of that page/modal.
  • Avoid negatives such as “don’t”. Instead, replace for a negative but active verb.
  • Avoid pronouns like “your” or “my” as they make copy longer.
  • Active voice

Primary buttons

  • Avoid “cancel” for a primary action unless:
  • Explicitly indicated in the glossary (“Cancel payroll run”)
  • It’s exactly the action the user is taking (“Cancel switch”). In those cases, consider if there’s a verb that could transmit the same information, e.g.: cancel subscription --> unsubscribe.
  • If you do use it, don’t use cancel for the secondary action.

Secondary and tertiary buttons

  • If their action is the opposite to what the primary action suggests, try using opposing verbs: subscribe/unsubscribe, remove/keep, etc.
  • Don’t shame users for not taking the primary action, e.g. “Continue without saving money”.

 

Copy do's and don'ts

Do
Button-Copy-DoDont-1-Do
Don’t
Button-Copy-DoDont-1-Dont

 

Do
Button-Copy-DoDont-2-Do
Don’t
Button-Copy-DoDont-2-Dont

 

Types

Heirarchy

Primary buttons

  • Only one primary action per-page or modal.
  • This is the main call to action; the main action should also appear or be highlighted in the title, so that they create a conversation.
  • Actions you want to highlight or recommend and that are part of the main process (Start/Next/Add/Save, etc.).
Button-Example-Primary

 

Secondary buttons

Actions that require less visual weight and emphasis on a screen because they start additional, collateral, or secondary processes within the main process (Edit/View, etc.)

 

Button-Example-Secondary

 

Tertiary buttons

  • Least important actions
  • Actions that are seldom taken or will back user out from the current process (i.e. Undo/Cancel/Exit/Skip/Dismiss/etc.)

 

Button-Example-Tertiary

 

Destructive buttons

Use for actions that:

  • Can’t be undone, or
  • Are difficult to recover, or
  • Have serious consequences (i.e. temporarily losing access).

This can be an action that destroys a users work, like deleting an employee, deleting a time card, etc.

 

Button-Example-Destructive

 

Do
Button-DoDont-Destructive-Do
Don’t
Button-DoDont-Destructive-Dont

 

Buttons with icons

An icon is optional. Usage:

  • Create an identifiable visual indicator for a common action or paradigm (ex: Secondary actions that are often reoccurring in different contexts, such as Add, Edit etc., for these icon will increase their recognition.)
  • Clarify an action if text alone is not enough to explain its functionality.
  • Call extra attention to a button

Right vs. Left icons

  • Right icon: typically for actions like a “right chevron” for “next” or a “down chevron” for an actions overflow.
  • Left icon: to reinforce a message, as in a “plus” sign for “add” or a “pencil” icon for “edit.”
Button-Example-Icons

 

Icon buttons

When to use

  • When an action is instantaneous
  • When the icon is part of common user’s mental model, ex: edit or delete icon
  • When saving real estate on screen is ideal, ex: in a dense table with multiple actions per row (see example below)

When not to use

  • For navigation. Instead, use the link component.
  • When there is plenty of room for a tertiary button, ex: a tiny edit icon (aka “baby pencil) at the far end of a card.

Tooltip on hover

(Desktop only)

The tooltip describes the icon button. Designers: if you’re creating a net-new icon button, please tell your engineering the icon name that should appear in this tooltip.

Button-Icon-Example-Tooltip

 

Examples

Button-Icon-Example-Payroll

 

Floating action buttons

When to use

  • When an action does not require a label. This requires the icon to be recognizable by most users, ex: chat or plus icon
  • When an action needs to be very handy at all times (a primary action)
  • When an action is in a context where saving real estate on screen is ideal, ex: adding a shift element in native app

When not to use

  • Do not use FABs for minor, overflow, unclear, or destructive actions.
  • Never use a Fab with a disabled state. For processes where certain FAB action is available through the whole process with exceptions, do not use disabled state for it, just simply don’t display FAB at all in that screens.

Placement

  • Always in front of all screen content, in most of the cases in right bottom corner (32px padding for Web, 16px padding for native app.)
  • Don't layer counters, text or other components on a FAB or in front of a FAB.

Example

Button-FAB-Example-1
Button-FAB-Example-2
Button-FAB-Example-3

 

Placement

A layout should contain a single Primary button indicating a CTA (that makes it clear that other buttons have less importance in the hierarchy). Primary button can be accompanied by medium-emphasis (Secondary) and low-emphasis (Tertiary) buttons that perform less important actions.

  • If buttons appear one next to the other, primary button should appear to the right.
  • If buttons appear on top of each other (mobile), the primary button should appear on top.
  • Space buttons 16px apart, whether stacking vertically or horizontally.
Button-Example-Placement

 

Fixed padding vs fill width

  • Fixed padding: the default for larger screens
  • Fill width: the default for mobile and some smaller desktop layouts
  • Never: use a fixed padding button in mobile
  • Always: use full width in desktop in smaller layouts, such as cards.
  • Always: use the default padding (24px left/right) when using fixed width (never customize this)
Button-Example-Fill-Padding

 

Best practices

Disabled states

Use disabled state for actions that aren’t currently available but will be available if the user does something. However, when possible, use enabled buttons.

The surrounding interface and the hint/tooltip should clearly explain why the button is disabled and what the user needs to do for it to become active.

 

How to avoid disabled states

Guide the user on the correct path using inline alerts and hints. If you are not sure if you can avoid disabling a button, reach out to the design team to brainstorm alternatives.

In the example below, the report controlled by this date range picker is only able to display 30 days at a time. In the first example, the user is able to select beyond 30 days, then the “Apply” button is disabled and an error message appears. In the alternative approach below, the user is immediately shown the 30-day alert when they select “custom.” Once they’ve chosen a start date, they may only select within 30 days.

Do
Button-DoDont-Disabled-Do

 

Don’t
Button-DoDont-Disabled-Dont

 

Examples

Button-Example-Disabled

 

Edit + cancel & save changes interaction

When tapped or clicked, an edit button should change to cancel/save changes button, and the form it controls should change from read-only to editable. When changes have been saved or cancelled, the button should return to “edit” and the form should return to read-only. If space is limited, you can use “Save” instead of “Save changes.”

Button-Example-Edit-Save-Cancel

 

Filter interaction

When showing/hiding a set of filters, the control should be this secondary style button with plural “Filters” + filter icon.

Behavior notes

  • Designer decides whether the filters are exposed or hidden by default
  • To open or close the filter area, the user taps on the “Filters” button
  • When filters are active, the count appears in parenthesis after the word “Filters”
Button-Example-Filters

 

Example: active filter

(example shows hidden filters)

Button-Example-Active-Filter

 

Navigation

Usually, navigation is reserved for hyperlinks, but there are rare exceptions where buttons are appropriate. Specifically, in stepped scenarios where back and next are needed. Use the terms “Back” and “Next” exclusively (not “go back” or “continue.”)

Button-Example-Navigation

 

Overflow actions

The “More actions” button allows a page to maintain a clean aesthetic that reduces cognitive load by consolidating numerous lower-level actions. Maximum of two levels of actions.

Button-Example-Overflow

 

Success / failure for processing interactions

For actions with a processing interaction, use the loading state of the button during the processing then swap the button component with a status pill using a fade-in / fade-out css animation. Pair the pill with a toast message.

Optional: return to the start.

Button-Example-Processing

 

Resources

(internal only)

Figma

Storybook

Jira