Buttons

Buttons allow people to take action, make choices, and move forward.

This information belongs to a pre-release version of the new buttons—more details are coming soon.
Cover

Principles

Actionable

Buttons need to be easy to spot and provide enough meaning for users to take the right action.

Contextual

Buttons are designed to fit every different context. For each context, a specific type of button is required.

Anatomy

Anatomy

Properties

Name

Values

Default

Size

Visual height and padding of a Button

MD SM

MD

Destructive

Signifies this action will cause data loss and can’t be undone

Boolean

False

Emphasis

The hierarchy level that defines its visual prominence

Primary (CTA only)

Secondary (Action only)

Tertiary

Primary (CTA only)

Secondary (Action only)

Label (Action only)

Hides the text label from the button. It will be displayed as a tooltip on hover/focus

Boolean

False

Disabled

Disables interaction and focus and signifies it

Boolean

False

Waiting

Signifies the action is taking place and can not be interacted with until it finishes

Boolean

False

Usage

When to use

Component

Per context

Label

Icon

Sizes

Emphasis

Use for

Call to Action Button

One or two, at the end

Always

Never

MD SM

Primary

The next best action:

1. Finish a task

2. Move forward in a flow

 

 

 

 

 

Tertiary

Dismissive actions:

1. Cancel

2. Skip
Complementary actions: 
Use sparingly

Action Button

One or many, inline

Optional, but default

Always

MD SM

Secondary

Most actions

 

 

 

 

 

Tertiary

Low emphasis actions:

1. Delete, in some contexts

2. (More) Actions menu toggle

Hierarchy and placement

Buttons emphasis levels

Buttons emphasis levels

CTA or Call to Action Button

CTA 1
CTA 2

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.

If the buttons were a conversation with the user, a Call to Action would be the equivalent of telling them, “This is the next best action to take”. If we tell them, “This is the next best action to take… but you can also do this, this, and this”, our recommendation becomes pointless.

 

⛔️ Don’t use CTA and Action buttons together

⛔️ Don’t use CTA and Action buttons together

⛔️ Don’t use two primary CTAs together

⛔️ Don’t use two primary CTAs together

✅ Combine Primary CTAs with tertiary CTAs

✅ Combine Primary CTAs with tertiary CTAs

Action Button

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.

If we turn it into a conversation, an Action would be the equivalent of saying “You can do this”. In that context, we can add more than one option to that phrase: “You can do this, this, and this.”
Action 1
Action 2

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

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

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

Destructive actions permanently cause data loss. Because they can’t be undone, they will always require user confirmation.

De-emphasizing destructive actions

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.

Arrangement

To be developed. Typically, we use the F pattern to arrange our buttons.

⛔️ Don’t place Primary CTAs at the end

⛔️ Don’t place Primary CTAs at the end

✅ Do

✅ Do

Main action first

Content guidelines

The goal of a button label is to clearly communicate the action taken by a person. It should be predictable, explicit, consistent, and scannable.

 

⛔️ Don’t

✅ Do

Use verb + noun combination to encourage action.

New

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

 

Go live!

Start testing

Don’t use all caps and title case.

USE THIS TEMPLATE

Use this template

 

Use This Template

Use this template

Don’t create conversational labels.

Yes, delete it

Delete

 

No, go back

Cancel

Be explicit and nongeneric. Clearly state what’s going to happen if a person selects a button.

Rename maze?

[OK] [Cancel]

Rename maze?

[Rename] [Cancel]

Be consistent. Don’t use different action labels within the same experience.

Delete maze?

[Remove permanently] [Cancel]

Delete maze?

[Delete] [Cancel]

Use device-agnostic and inclusive labels whenever possible.

Click

Select

 

See

View

Most common button labels

Add

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

Apply

Immediately puts changes into effect without closing the window, for example, when using filters.

Cancel

Use when a person decides to undo an action. Don’t use undo.

Create

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

Delete

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).

Get started

Avoid. Get started is generic and ambiguous. Choose a more explicit button label.

Go to

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).

Invite

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.

Remove

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

Save as

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


Further reading

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.

Behavior

States

The state of a component can depend on properties set before the user can interact with it. We call them state properties. Differentiating them from the user-triggered states allows us to combine them, creating richer states that cover the whole interaction spectrum. Learn more about interaction states →

Default

Default

Destructive

Destructive

Disabled

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.

⛔️ Don’t

⛔️ Don’t

Disabled buttons can be confusing, users need to figure out how to activate them instead of focusing on their tasks

✅ Do

✅ Do

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.

⛔️ Don’t

⛔️ Don’t

Do not show disabled buttons that never will be available for users

✅ Do

✅ Do

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.

Disabled-5

Width

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.

Intrinsic width

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.

Intrinsic 2
Intrinsic 1

Full-width

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.

Full 1
Full 2

Minimum touch targets

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.

Touch targets

Breakpoints

The size of the container where buttons are placed defines the type of buttons displayed and their shape.

Button width display

This section is under construction—more details are coming soon.

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.

Breakpoint 1

Concealing more options

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.

Concealing