Buttons and Actions
A button's visual hierarchy — primary, secondary, destructive — communicates the relative weight of actions and guides users toward the intended next step.
Every screen has a primary action. Presenting all actions at equal visual weight — the same size, the same colour, the same emphasis — forces users to read every label before deciding what to do.
The hierarchy
Buttons exist in a hierarchy that reflects the relative importance of actions. A primary button is the main call to action — the one the system recommends or expects. There should be at most one per context. A secondary button is an alternative or supporting action — less urgent than the primary. A tertiary or ghost button handles low-priority actions. A destructive button signals irreversible or dangerous actions — it is visually distinct to require deliberate intent.
Label clarity
Button labels should describe the action in specific, verb-first terms. “Submit” is vague. “Save changes” is specific. “Delete” is alarming without context. “Delete account” communicates the scope. Avoid labels like “OK”, “Yes”, “No” — they require the user to hold the preceding question in mind to interpret them. Rephrase so the button itself contains the full instruction: “Cancel subscription” rather than “Yes”.
Icon-only buttons
Icon-only buttons remove the cognitive overhead of reading a label but create a discoverability problem — the icon’s meaning must be known in advance or discoverable from context. Reserve icon-only buttons for universally understood actions (close, search, menu) or actions in toolbars where space is constrained and the user has established context. Always provide an accessible label even when the visual label is absent — via aria-label on the button element, or visually hidden text inside it. A close button rendered with an × and no accessible name announces only ”×” to screen readers. <button aria-label="Close dialog">×</button> announces “Close dialog”.
States
Every button needs a complete set of states: default, hover, active (pressed), focused, loading, disabled, and — for destructive buttons — a confirmation step. A disabled button that gives no indication of why it is disabled creates confusion. Where possible, keep the button enabled and show a validation error on activation rather than hiding the action entirely.
The takeaway
On every screen, identify the primary action and make it visually dominant. Use the secondary and tertiary hierarchy for supporting actions. Write specific, verb-first labels. Design all states — including loading and error — before shipping. A button is not complete when it looks right; it is complete when it behaves correctly in every state.