A button lets the user perform an action with a tap or a click.
There are two different types of button that, default and negative, these designed to emphasise the nature of the action.
Priorities set a visual hierarchy amongst the buttons displayed on the screen to help more important buttons to take precedence over others.
The most important action to move forward in a flow, acknowledge and dismiss, or finish a task.
You should always have one primary button per page where relevant, this can contextually change if another action needs to be completed before being able to proceed.
Use secondary for providing alternatives to the primary action, or when none of your actions are more important than the others.
Use secondary neutral for less important convenience actions, such as copying information like bank details with a button, controls or for navigation.
There are three different button sizes, small medium and large, each used for different purposes.
The large button is used to move users forward in a flow.
It’s used at full width on mobile and auto-width, adjusting to the content on desktop depending on use case.
The medium button is used for in line content that needs a greater emphasis than small button or that simply needs to be kept in line with other content on the same line — For example in the nav where you have a 40px close or back icon button.
Medium supports icon left and right, and single or double avatars and wraps to the content.
The small button is used for smaller in line content such as list items.
Small button supports icon left and right and wraps to the content.
Unless the button is disabled, the user can tap or click on it to perform the action assigned to it.
The button should always be contextual, which is why it should be used in line with the content. This gives a stronger cohesion between the context and the action that it performs.
On mobile, if an action must be taken by the user, for example, to finalise something or proceed in the current process, it is best to keep the button visible all the time.
You can do this by pinning it to the bottom of the screen, outside of the scrolling area. Please pin only one primary action per screen.
When using buttons on mobile, remember that their height may change based on the user's system-wide preferred font size for accessibility.
For screen reader users, the button's title is read aloud. This emphasises the importance of contextual titles, ensuring all users understand the button's action.
Keep button copy concise. Longer text is harder to scan and increases cognitive load. Also, consider that text length may double when translated.
To ensure users always know what will happen when they interact with a button, the text must be fully visible in all supported font sizes and languages. We don't truncate button text; instead, we allow it to wrap, and the button area grows accordingly.
On small devices, buttons with more than a few words can dominate the screen, reducing the usability of other elements—especially if the button is pinned to the bottom.
Consider providing alternative cues explaining why a button is disabled, ensuring screen readers can convey this information, or rethink the design so that buttons are always enabled but provide feedback on required steps before proceeding (e.g. form validation).
Button copy should:
start with a verb, like ‘Pay’ or ‘Send’
be just a few words (ideally 1 or 2)
describe the action (if someone only reads the button, they should know what will happen next)
connect to the content around it — for example, it might use the same words as the title
avoid using first person pronouns like ‘me’, ‘my’ and ‘I’
be in sentence case (only capitalise the first letter of the first word)
have no full stop
Platform | Available | Developer documentation |
|---|---|---|
Android | ||
iOS | ||
Web |