Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Components
  2. Button
  3. Usage

Button

Usage

Overview

Button is the default actionable control for committing tasks: submit a form, confirm a modal, launch an export, acknowledge a callout. Dispatch leans on Secondary as the baseline and elevates a single Primary or Critical action per region so operators always know the safest default. The rule is emphasis discipline—every visual surface has exactly one "most important" action, and everything else is peer-level or lower. Mixing two primaries in one region forces the eye to choose, which is the failure mode buttons are supposed to prevent.

When to use

  • Explicit commits: save, apply, acknowledge, confirm, transfer, escalate.
  • Toolbar and footer actions where the click target must be obvious on touch and pointer.
  • Button-styled navigation to a destination operators commit to (opening a takeover workflow, starting a new incident).

When not to use

  • Plain route navigation that should look and behave as a link—use a link style.
  • Destructive bulk operations without a confirmation step—route through Modal.
  • Icon-only dense actions in toolbars—use IconButton with an accessible name.
  • Two mutually exclusive modes—use SegmentedControl.
  • A binary setting with a prose label in a form—use Switch.
  • An icon-only two-state control in a toolbar—use IconToggle.
  • Mutually exclusive pressed options in a cluster—use ToggleGroup items (ToggleGroupItem), not Button with toggle.

Types

TypeEmphasisTypical use
PrimaryOne per regionThe safe, committed happy path
SecondaryPeer levelMost dispatch buttons—cancel, apply, edit, close
SecondaryAltDe-emphasized peerA secondary next to another secondary when only one should be visually weighted
CriticalSingle attention callHigh-stakes commits (rare; reserved for safety-critical flows)
DestructiveDelete, remove, revokeDestructive verbs with destructive styling; always confirmed
LinkLowest emphasisNavigation-styled actions that don't carry commit weight

Content guidelines

  • Title case labels with active verbs; drop articles ("Add User", not "Add a User"). Localize with formatMessage.
  • Lead icons disambiguate similar labels ("Export CSV" vs. "Export PDF"); trailing icons hint at post-click behavior (opens an external window, reveals a menu).
  • Reserve exclamation and color for the component's type—don't rewrite "Save" as "Save!" to push urgency.

Behavior and states

  • Link navigation. Use type={ButtonType.Link} with href for real destinations. Without href, the control does not navigate—even when it looks like a link.
  • Loading. Show in-button progress and disable repeated submits; never leave the button enabled while a request is in flight.
  • Disabled. Surface why nearby (helper text, callout, or tooltip) when it isn't obvious. A disabled button with no rationale is worse than no button at all.
  • Full width. On tablets and dispatch-on-mobile layouts, a primary commit often spans the row; keep peers as inline buttons so the primary visually lands.
  • active vs toggle. active forces momentary/open styling (brightness or transparent-active backgrounds) without aria-pressed. Use toggle with pressed / defaultPressed / onPressedChange when the control must stay pressed and announce sustained state. Sustained data-state="on" styling: selected inset fill on ButtonType.Secondary; brightness(var(--brightness-active)) on filled types (Primary, Critical, SecondaryAlt, Success, Destructive).

Best practices

Do

  • Place the primary action consistently across the product—trailing in modals, upper-right in page headers, bottom-right in drawers. Muscle memory matters during a shift.
  • Elevate only one Primary or Critical per region. Two primaries in the same frame is almost always a design problem wearing two coats.
  • Pair Destructive with explicit copy ("Remove", "Delete permanently")—never rely on color alone.

Don't

  • Use the small size as the only touch target in critical response flows without adequate spacing.
  • Ship a disabled button with no explanation of the precondition. Say why.
  • Stack a Primary next to a Critical in one region; the emphasis escalation is ambiguous.
  • Over-ornament with multiple icons on a single button—one icon, not two.

Accessibility

Buttons surface visible focus rings, accessible names, and disabled states that assistive technology can announce. See Accessibility for the keyboard model, labelled-by patterns, and disabled-state contract.

Related Components

  • Icon button for compact icon-only actions with tooltips.
  • Button group for clustered peer actions.
  • Split button for a primary action with related alternates.
  • Modal for confirmation framing after a destructive click.

Previous

Breadcrumb / Accessibility

Next

Button / API and Development

On this page

Overview
When to use
When not to use
Types
Content guidelines
Behavior and states
Best practices
Accessibility
Related Components