Button

Motion design for buttons

Overview and triggers

Buttons have simple motion options which can be triggered by a tap on the button, a hover over, or leaving the button.

Motion can (optionally) be applied to the following elements:

Gestural considerations for mobile / tablet

A press on a button mimics a hover for desktop.

Technical detail

Motion design for gradient Ai button

Gif showing how an AI button should animate.

Star icon spec

| item | motion | bezier - percentage | duration | time in example | | --- | --- | --- | --- | --- | | star | scale | 0.66, 0.00, 0.34, 1.00 - 100% | 0 | 167ms | | star | scale | 0.17, 0.11, 0.83, 0.89 - 75% | 400ms | 567ms | | star | scale | 0.17, 0.00, 0.34, 1.00 - 100% | 400ms | 967ms | | star | rotation - 0 - 90 | 0.66, 0.00, 0.83, 1.00 -0.17, 0.00, 0.34, 1.00 | 800ms | 167ms - 967 |

Border spec

Labels

State what happens

A button label should indicate the action that happens when users select the button. Use the same word or phrase found in other parts of the experience.  

Be concise, but prioritize clarity

Make button labels as short as possible without compromising clarity. 

• Use 1-2 words, and no more than 3 words, if possible.
• Don't use punctuation, such as periods, exclamation points, or commas.
• Avoid unnecessary words and articles, like the, an, or a. 
• Use fewer than 20 characters, including spaces. 

In other words, make every character audition. If the meaning is still clear without a word, phrase, or punctuation mark, don't include it. If you need to add something back to bring back clarity, that's okay. Clarity always trumps brevity.

Consider translation

Find the maximum number of characters that can be displayed and make sure the English label leaves enough space for longer languages.

Communicate the restrictions to translators.

Use sentence case

Always use sentence case capitalization, which means capitalize only the first letter of the first word, except for proper nouns like trademarks and place names. Never use all caps for emphasis. 

Make the first word a verb

Button labels should always lead with a strong verb that indicates what happens when users select the button.  

Note: Because Draft is more commonly used as a noun, using it as a verb could create confusion for English readers as well as for translation teams. The Draft with Copilot pattern is an exception

Use the right tone

Avoid emojis and exclamation points to keep buttons as functional and scannable as possible. This helps minimize distractions for users.  

Use consistent terminology

Use consistent button labels across products.

OK and Done

It's best to avoid using OK or Done except in a few use cases.

• You can use OK when the only action is to read and dismiss the message.
• You can use Done when a series of steps is complete or when agreeing to terms.

Requirements

Users of assistive technology should be able to:

• Navigate to and activate a button.
• Use a button to perform an action. 

Interactions

Buttons should be used to perform actions. For example: 

• Submit a form.
• Trigger a change in the UI, such as open a modal or expand a section of content.
• Control media content, such as play and pause on a video.
• Trigger a function, such as save, delete, or refresh.

Disabled button states should be avoided where possible as they pose multiple barriers for users. For example:

• Disabled elements are often low contrast, making them difficult to see.
• Some users may not understand why an element is disabled and become frustrated if they cannot perform an action.

Mouse interactions

• Buttons should have a clear hover state to help indicate that the element is interactive.
• When hovered over with a mouse, the cursor should change to a pointer.
• The hit area should have a minimum target size of 24 x 24px.
• If the pointer is pressed down on the button but released outside, the action is not performed.

Keyboard interactions

• Tab. Moves focus from the previous interactive element to the button.
• Enter or Space. Activates the button.

Design considerations

• Icon only buttons should only be used on small screen sizes or if the icons are universally recognisable.
• Use clear, descriptive labels.
• The minimum colour contrast between the button background and button text should be 4.5:1.

Development considerations

• Buttons should have clear accessible names, conveyed by the inner button text.
• Where icon only buttons are used, make sure they have a clear accessible name conveyed by an aria-label.
• If multiple buttons have the same name, use aria-describedby to specify the content the button relates to.
• Make sure that button actions can be cancelled by the user if they activate the button accidentally.
• Trigger button actions on click or pointerup, not pointerdown.