Button
Buttons trigger an action, such as submitting a form, closing a dialog, or navigating to a new page.
- Highest-priority actions
- Use once per section
- Examples: Submit, Confirm or Save
- Non-critical actions
- Examples: Back, Cancel, Edit or Add
- Tertiary actions
- Examples: View terms, Back or Close
- Group inside a Action Group for related actions
- Non-critical actions
- Examples: Back, Cancel, Edit or Add
- Tertiary actions
- Examples: View terms, Back or Close
- Group inside a Action Group for related actions
- Purpose: Neutral
- Examples: Close, Exit, Edit
- Use when purpose is neither constructive or distructive
- Highest-priority actions that are required to complete the user’s task
- Only used once per screen
- Represents a constructive action
- Examples: complete, approve, resolve, add etc.
- Represents actions that could have destructive effects on the user’s data
- Examples: delete or remove
The icon-only button is a separate component in Figma.
- Examples: toolbar or in the
metaslot of a card - Clarify the purpose of the button using a tooltip
- Place
ghostappearance buttons inside an action-group
The smaller size buttons (condensed and super-condensed) are useful when used inside other components (inside data-grid-cell or action-group for a toolbar) as they take up less space.
- Cause deception
The call to action text draws users to click, but nothing happens. This causes confusion, leading users to think that the interface is broken. - Insufficient contrast
Even if the button is disabled, the button label is still crucial for understanding the interface. - No feedback
Without feedback, users don't know what has gone wrong or how to fix the error. - System complexity
Disabled buttons are often used to prevent wasteful clicks, but this puts pressure on the design / implementation to provide robust inline validation. The reality is, inline validation systems can fail, leaving the user stuck with a disabled button and no way to complete the form.
While disabled buttons often create more problems than they solve, there are limited scenarios where they can improve the user experience if designed carefully:
- Preventing duplicate submissions
After a critical action such as submitting a payment, booking, or form, the button can be temporarily disabled to avoid multiple clicks and duplicate transactions. This should always be paired with visible feedback (e.g., changing the label to “Processing…” and showing a spinner). We have thependingfeature for this situation. - Communicating temporary unavailability
Buttons may be disabled while content is loading or while a dependent process finishes (eg. waiting for a verification SMS). This should be short-lived, and the button state must be updated as soon as the action becomes available.
- Always provide visible and accessible feedback when a button is disabled (e.g., helper text, inline validation, or an explanatory tooltip).
- Prefer inline error messages and contextual feedback over disabling buttons—this often gives a clearer and more usable experience.