Vivid API

Button

Buttons trigger an action, such as submitting a form, closing a dialog, or navigating to a new page.

Appearance

Filled

  • Highest-priority actions
  • Use once per section
  • Examples: Submit, Confirm or Save

Outlined

  • Non-critical actions
  • Examples: Back, Cancel, Edit or Add

Ghost

  • Tertiary actions
  • Examples: View terms, Back or Close
  • Group inside a Action Group for related actions

Outlined Light

  • Non-critical actions
  • Examples: Back, Cancel, Edit or Add

Ghost Light

  • Tertiary actions
  • Examples: View terms, Back or Close
  • Group inside a Action Group for related actions

Connotation

Accent

  • Purpose: Neutral
  • Examples: Close, Exit, Edit
  • Use when purpose is neither constructive or distructive

CTA

  • Highest-priority actions that are required to complete the user’s task
  • Only used once per screen

Announcement

Success

  • Represents a constructive action
  • Examples: complete, approve, resolve, add etc.

Alert

  • Represents actions that could have destructive effects on the user’s data
  • Examples: delete or remove

Icons

The icon-only button is a separate component in Figma.

Use Icon-only buttons when space is limited

  • Examples: toolbar or in the meta slot of a card
  • Clarify the purpose of the button using a tooltip
  • Place ghost appearance buttons inside an action-group

Do use left icons to emphasize meaning and right icons to imply directionality or to indicate a button will open a menu.

Don’t use left icons to imply directionality or to indicate a button will open a popover. Don’t use right icons to emphasize meaning.

Size

Use smaller size buttons when space is limited

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.

Use same button size for adjacent buttons

Don’t use different size buttons for adjacent buttons”

Ghost Buttons

Use ghost buttons inside a container

Don’t use ghost buttons without a container

Disabled Buttons

Disabled buttons often create confusion and poor UX.

They can feel deceptive—users are drawn to click a clear call to action, but nothing happens. Without feedback, it’s unclear what went wrong or how to fix it, and reduced contrast can make labels harder to read. Since placeholders are only hints, blocking progress with a disabled state often shifts too much responsibility onto validation systems, which can fail and leave users stuck.

In most cases, it’s better to keep buttons enabled and provide clear, inline feedback. Disabled states can still be useful in limited scenarios, such as preventing duplicate submissions (e.g. showing a “Processing…” state) or indicating short-lived unavailability while something loads. In all cases, ensure users get clear, accessible feedback explaining what’s happening and what to do next.