Buttons allow people to take action, make choices, and move forward.
Buttons need to be easy to spot and provide enough meaning for users to take the right action.
Buttons are designed to fit every different context. For each context, a specific type of button is required.
Visual height and padding of a Button
Signifies this action will cause data loss and can’t be undone
The hierarchy level that defines its visual prominence
Primary (CTA only)
Secondary (Action only)
Primary (CTA only)
Label (Action only)
Hides the text label from the button. It will be displayed as a tooltip on hover/focus
Disables interaction and focus and signifies it
Signifies the action is taking place and can not be interacted with until it finishes
Call to Action Button
One or two, at the end
The next best action:
1. Finish a task
2. Move forward in a flow
2. SkipComplementary actions: Use sparingly
One or many, inline
Optional, but default
Low emphasis actions:
1. Delete, in some contexts
2. (More) Actions menu toggle
Buttons emphasis levels
To guide the user over what action to take next, we need to understand first which one is the most important within a specific context in their flow. Our hierarchy emphasizes the next best action over anything else, so it’s easier to scan and allows people to take that action immediately. As Call to Actions are always unique, they’ll never need an icon to reinforce their label.
When we suggest people do something important that allows them to move forward in a flow, we don’t want other things to get in the way. Hence, Call to actions always go alone and are displayed at the end. Alternatively, we can display an opposite action next to it to give people a way out, letting them do nothing, dismiss, or skip. These opposite actions use the Tertiary emphasis level.
⛔️ Don’t use CTA and Action buttons together
⛔️ Don’t use two primary CTAs together
✅ Combine Primary CTAs with tertiary CTAs
They are the most used actions in the interface. They can go alone or group with other actions. That’s why they always have leading icons that reinforce the meaning of the text label and facilitate scanning the different options more easily.
When there’s no next best action to suggest, or people are in the middle of a flow inside a given context, we will use the Secondary emphasis level as default
Displaying more options
If we want to display a list of more options hidden inside a menu, we will use Tertiary emphasis to differentiate that Action from the rest.
Hiding text labels
When the horizontal space is limited, you can optionally hide the Action’s label, relying only on the icon to convey its meaning. These actions display a tooltip that shows the label on mouse hover or keyboard focus. Use sparingly.
Destructive actions permanently cause data loss. Because they can’t be undone, they will always require user confirmation.
De-emphasizing destructive actions
When a destructive action isn’t the next best, we might want to reduce the Action’s emphasis to Tertiary to reduce its visual prominence and avoid distractions.
To be developed. Typically, we use the F pattern to arrange our buttons.
⛔️ Don’t place Primary CTAs at the end
Main action first
The goal of a button label is to clearly communicate the action taken by a person. It should be predictable, explicit, consistent, and scannable.
Use verb + noun combination to encourage action.
Create new project
Use one to three words. Be brief and straightforward. Use words such as new, this, your, next with caution—only when necessary to fully communicate the result of an action.
Create your first project folder
Create project folder
Reduce punctuation—skip commas, articles, exclamation marks, and question marks.
Return to the homepage
Return to homepage
Don’t use all caps and title case.
USE THIS TEMPLATE
Use this template
Use This Template
Don’t create conversational labels.
Yes, delete it
No, go back
Be explicit and nongeneric. Clearly state what’s going to happen if a person selects a button.
Be consistent. Don’t use different action labels within the same experience.
[Remove permanently] [Cancel]
Use device-agnostic and inclusive labels whenever possible.
Use add when a person puts an object in a new place or experience (for example, a prototype) and when they add objects one by one or in bulk (cards, blocks, etc.). → See also: Create, Invite
Immediately puts changes into effect without closing the window, for example, when using filters.
Use when a person decides to undo an action. Don’t use undo.
Use it when a person is about to make something new from scratch, especially when it’s a multi-step process, such as creating a maze or a project. Avoid using New, especially when it’s not accompanied by a noun. → See also: Add
Removes objects so they’re no longer available and can’t be restored. Don’t use in relation to people, for example, delete participant or delete user. In cases like that, it’s better to change the perspective to avoid the dehumanizing tone (delete profile, delete user data, etc).
Avoid. Get started is generic and ambiguous. Choose a more explicit button label.
Directs people to a particular place (for example, Go to Reach). When directing to the homepage, use Return instead. When referring to objects, use verbs (for example, write View report instead of Go to report).
Use invite when people want others to join Maze as it feels more human and conversational. Avoid using add.
OK, Done, Got it
Whenever possible, use context-specific, explicit labels led with verbs.
Don’t use OK it as a label when informing about maintenance breaks or new features, and when explaining how things work. Use Got it instead.
Don’t use OK or Done as a label when a person is about to confirm changes made. Use Save instead.
To remove something means we take away an object from the context or experience. The object isn’t deleted—it still exists. For example, we remove team members from a team. → See also: Delete
Use Save as when creating a new object from existing content or data, for example a segment created based on applied filters, or a template based on maze. → See also: Create
UI Copy: UX Guidelines for Command Names and Keyboard Shortcuts
Labels for commands should be brief, informative, rely on verbs and adjectives, and avoid branded terms. Command shortcuts must limit the number of modifiers and follow standard conventions.
There may be good reasons for disabling buttons by default. Sometimes we want to make it harder for our users to make mistakes and avoid unnecessary layout jumps between error messages. Or sometimes, we want to point out that something important is missing before moving on to the next step.
But disabled buttons only communicate that something is wrong; they don't explain why. As a result, many users—especially non-tech-savvy ones—often get stuck wondering what's missing or what they've done wrong and end up frustrated. We are not helping them fix the problem and move forward, which should be our priority.
They also pose various accessibility problems. The most important one is that disabled buttons are usually not focusable and therefore cannot be accessed by users with a keyboard.
Here is a series of recommendations on what to do in certain situations.
In forms, show the resting button by default, If the user hit it and there are existing actions to perform, provide them with carefully crafted in-context error messages. This will remove complexity and prevent users to think why the button is disabled at first place.
Disabled buttons can be confusing, users need to figure out how to activate them instead of focusing on their tasks
Let the user freely hit the button and provide carefully crafted in-context error messages if something is missing
In cases when there are multiple profiles, can happen that a user do not have the rights to perform an action. In that cases, instead of showing a disabled button, try to hid the action itself. Use proper affordances to highlight that the action can not be conducted and why.
Do not show disabled buttons that never will be available for users
When the action won't ever be available for the user, hide the button instead of showing a disabled one
When, in order to unlock a key action, other important actions out-of-context need to be triggered on the interface, disabled buttons are in need. In these cases, make sure you provide enough context to users to unlock this action.
Buttons are split in 2 types depending on the container where are placed or the content they are built with. To understand when to display one or another visit the breakpoints section.
Mainly displayed on wider screens, the width of this kind of buttons is created by the content they hold: paddings, label and iconography. When the mix of the button content + paddings doesn’t reach 96px width, we use a min-width property to ensure button is tappable enough.
These buttons use the full width of the container they are placed in, till they find a limit, normally a spacing. The content inside these buttons remains centered, while the container expands. When it comes to arrangement they follow the same pattern used on wider screens, most important action first.
Adequately sized touch targets help users to avoid errors and complete actions faster. Our buttons are designed to follow the standards, thats why we stablished a minimum of 48x48 target area for IconOnly buttons combined with min-width for SM and MD Buttons.
The size of the container where buttons are placed defines the type of buttons displayed and their shape.
When it comes to display a full-width button or an intrinsic one, we use the container size where the button is placed as an indicator. Buttons placed inside a container with a 440px width or less will display full width.
When a group of secondary actions are displayed, full container space available will be taken by the buttons. If the container gets smaller, button group gets concealing progressively under a “More options” tertiary button.