Button
Interactive elements that help users take actions within an interface.
Buttons are selectable elements that allow users to take action. They typically communicate a call to action (CTA) using text, icons, or both. Buttons are utilized across a range of interfaces including dialogs, forms, and content cards.
Also known as: Push button, actions drop-down, action menu, UI button (Native iOS), button (Android), elevated button (Flutter).
Anatomy
A. Leading icon (optional): Icon located before the button text used to enhance the meaning of the text.
B. Label (required): Text communicating what action will be performed when the user interacts with it.
C. Trailing icon (optional): Icon located after the button text used to enhance the meaning of the text.
Usage
Component | When to use | When not to use |
---|---|---|
Primary button | To emphasize the most important or common call to action. | For actions of equal importance to others or another primary button. |
Secondary button | For calls to action that are less important or the opposite of the primary. | For the principle or most important action or without a primary button. |
Tertiary button | For the least important call to action. For sub actions when the primary and secondary are present. | For actions of high use or importance. For destructive actions that might be accidentally selected. |
Destructive button | To emphasize that an action could have a destructive or irreversible effect, such as deleting data. | For non-destructive actions. |
Icon button | For displaying actions in a compact area. To implement buttons with more visual appeal. | When the meaning of an icon is unclear. When icon buttons aren’t consistently used within the UI. |
UI Icon button | Within components and when the action is universally recognized. | When the meaning of an icon is unclear. |
Best practices
- Only use buttons for actions, not navigational elements. Use a Link to take users to a new destination.
- Use consistent design, placement, and behavior for buttons throughout interfaces. This helps users predict interactions.
- Avoid using more than five text buttons per interface. Consider using a Dropdown menu to group more than five actions.
- Group buttons into logically based on the relationship or tasks users are trying to accomplish with your interface.
Do Use leading or trailing icons with text labels when appropriate and commonly associated with the action.
Don't Use leading or trailing icons when they are not commonly associated with the action.
Primary buttons
Primary buttons are high emphasis and use fill to draw attention. They can be used independently or in groups where one call to action needs to stand out more than others.
- Use them sparingly to draw attention to the most important action on a screen.
- Place primary buttons in expected locations, ensuing they are easy to find and follow the natural flow of the page.
Do Use one primary button per screen, not including headers, dialogs, content cards or panels.
Don't Use multiple primary buttons per screen. This can distract users, causing uncertainty about the next action.
Secondary buttons
Secondary buttons are medium emphasis and use an outline with no fill. They’re commonly paired with primary buttons to perform the opposite or negative action compared to primary buttons, for example “Next” and “Back”, or “Submit” and “Cancel”. However, they can also be used independently or in groups.
- Use secondary buttons for common actions when high emphasis isn’t needed.
Do Use primary and secondary button styles together to express different levels of emphasis.
Don't Use more than two secondary buttons for smaller, mobile interfaces or three for larger, web experiences.
Tertiary buttons
Tertiary buttons are the least prominent compared to primary and secondary buttons. They can be used independently or in groups with primary and secondary buttons for less important actions.
- Use tertiary buttons for less important, less frequently used actions. Overuse can dilute their meaning and confuse users.
- Ensure tertiary buttons are easy to locate and not so subtle that they’re easy to overlook or hard to interact with.
Do Place tertiary buttons in a location that doesn't interfere with the main workflow.
Don't A tertiary button labeled with primary call to action <Submit.>
Destructive buttons
Destructive buttons should be used sparingly. They have three styles: primary, secondary, and tertiary.
- Alert users with a warning dialog before a destructive action happens, especially if resulting in data loss.
- Prevent data loss by placing destructive buttons where they’re less likely to be selected by mistake.
- Allow users to undo destructive actions when possible to give users more control over their actions.
Do Use both color and and descriptive labels to ensure destructive buttons are accessible.
Don't Use more than two primary destructive buttons per screen as it can lead to confusion or accidental selections.
Do Pair icons with destructive buttons to enhance the meaning of the button.
Don't Use icons alone for destructive buttons, as these could lead to user error or data loss.
Icon buttons
Icon buttons are circular, enclosed icons that represent an action. They include an optional label and are available in a medium and large size. Unlike text buttons, icon buttons offer visual appeal and stack vertically in limited horizontal space.
- Use icon buttons thoughtfully, don’t add visual appeal for the sake of visual appeal.
- Size icons consistently and use or exclude icon button labels across experiences.
Do Use icon buttons without labels when their meaning is clear.
Don't Use unlabeled icon buttons when their meaning is unclear.
UI icon buttons
UI icons buttons are visual representations of an action that don’t require labels. They exist within other components or on their own.
- Ensure icons clearly and intuitively indicate the action they represent.
- Make sure UI icons are large enough to be usable, especially on touch devices.
Do Use one UI icon within a component.
Don't Create clutter by using too many UI icons in a component.
Order
Order refers to the sequence of buttons and which action comes first in a group. Buttons should be ordered logically based on user expectations. This frequently aligns with reading order, meaning primary buttons appear on the left for left-to-right languages. However, common exceptions exist. For example, navigational buttons in a form or wizard where “Next” would be placed in the right position to indicate forward progress.
- Be consistent across your interface. If the primary action is usually on the left, avoid switching it for specific instances.
- Group related actions, for example, “Cut”, “Copy”, and “Paste” are often grouped together in text editing interfaces.
Do Place the 'Back' button to the left of the 'Next' button to follow the natural reading order for left-to-right languages.
Don't Assume the same logical order applies to right-to-left languages where users may have different expectations.
Alignment
Alignment refers to the position of buttons or button groups along a common edge within a container. In left-to-right languages, users typically scan content left-to-right, then top-to-bottom. Buttons should follow this pattern and align with the content within the container to match these expectations.
Buttons within components are typically left-aligned except in wizards, touring tips, or components with full-width buttons.
- Left-align buttons by default for left-to-right languages so it’s easier for users to scan content along a common edge.
- Right-align navigational buttons to reinforce that there will be forward progress.
Size
Text and icon buttons are available in medium and large sizes. UI icon buttons are available in small, medium, and large sizes.
Medium buttons
Medium buttons are the default button size for most use cases, such as forms and dialogs.
- Use medium buttons to allow space for interfaces with multiple interactive elements.
Large buttons
Large buttons are more expressive and may balance large headings commonly found across landing or web pages.
- Use large buttons when space is available and there are few other interactive elements present.
Behaviors
Styling and coding buttons and links
In general, buttons should be used for in-page actions and links should be used as navigational tools, like leaving a page. Whenever possible, match the visual styling of these elements with their coded and user-expected behavior. However, buttons and links may be styled like one another in some cases. Learn about these exceptions below.
Button coded as links
Buttons may be coded as links but styled as buttons when necessary. For example, an icon button may be appropriate when linking to a shopping cart.- Use the arrow icon whenever possible as a visual cue that selecting will navigate to another page.
Link coded as buttons
Links may be coded as buttons but styled as links when necessary. For example, buttons may be styled as links when information will be presented in an overlay or dialog.- Avoid underlining links coded as buttons, as this style is reserved for links, not buttons.
Content
- Always use sentence case except for proper nouns or acronyms.
- Use clear, actionable, language that is easy to understand without additional context or information.
- Avoid abelist verbs that focus on senses. For example, use “Play video,” instead of “Watch video” or “Explore results” instead of “See results”.
Button formulas
- Combine action or command verbs with nouns to make buttons specific.
- {verb} + {noun} is useful for most product cases.
- {verb} + {adverb} is typically used for marketing and promotions.
- Only use single word labels for common navigational actions such as, “Next,” “Continue,” “Back,” “Close,” “Cancel,” “OK,” “Accept,” “Done,” or “Finish.”
Do Ensure button text helps users predict what will happen.
Don't Use vague language that is not descrptive.
Do Ensure all button labels clearly indicate a single action that will happen when selected.
Don't Include multiple actions in one button. This creates confusing and long labels that wrap on multiple lines.
Do Limit button labels to one to three words.
Don't Include articles such as “a”, “an”, or “the”.
Do Use a question mark to add meaning for “Forgot password?” or “Forgot username?” button labels.
Don't Include punctuation in any other button label as they don’t add meaning to button labels.
Platform considerations
Mobile
Full-width buttons
Full-width buttons make it easier for users to select options on mobile devices and reduce the chance of missed selections.
- Use full-width buttons within containers when users would benefit from extra touch space.
- Avoid using more than two full-width buttons per container to help prevent accidental selections.
Stacked buttons
Stacked buttons adds visual balance and provide a larger touch area on small screens.
- Arrange buttons in a vertical stack at the bottom of the screen to use the available space more effectively.
- Avoid stacking too many buttons to prevent overwhelming the user. Limit the options to the most important actions.
- Help users prioritize actions by placing the most important or expected button at the top.
Icon buttons as navigation
Icon buttons can be used in mobile interfaces to provide compact navigation.
- Only use icons as navigation when the icon is commonly understood.
- Use text in addition to the icon if an icon can be interpreted in multiple ways.
- Maintain consistent styles for icons. This includes the design as well as placement and behavior.