Components

Buttons

The most fundamental interactive element in any UI. Buttons trigger actions and must clearly communicate what will happen when clicked.

#buttons#CTA#interactive#actions#primary#secondary#loading state

What is it?

A button is an interactive element that triggers an action when activated. It is distinct from a link (which navigates) and from a toggle (which changes state). Buttons are the most frequently-used interactive components in digital products and must communicate their purpose, state, and affordance clearly.

Why it matters

Buttons are the moment of conversion. Every primary action — submit a form, complete a purchase, create a project, send a message — is a button click. Poor button design causes hesitation, missed actions, and abandoned flows. Well-designed buttons communicate instantly: what they do, that they're clickable, and what state they're in.

Best Practices

Label with action verbs: "Save Changes," "Create Project," "Send Message." Never "OK," "Submit," or "Yes."
Only one primary button per screen. Multiple primary actions create a hierarchy problem.
Button labels should describe the outcome, not the action: "Book Table" not "Click Here."
Use sentence case for button labels, not Title Case or ALL CAPS.
Loading states must exist for any button action that triggers an async operation.
Disabled buttons need a reason — either a tooltip or inline text explaining why.
Minimum touch target: 44×44px on mobile. Visual size can be smaller if the clickable area is not.
Destructive buttons (delete, cancel, remove) must be visually de-emphasized — use a secondary or danger style, never a primary style.
Group related buttons consistently — confirm on right, cancel on left (desktop convention).
Icons can supplement labels but rarely replace them. Icon-only buttons need accessible labels.

Common Mistakes

"Submit" as a button label on any form — tells the user nothing about what will happen.
Multiple primary buttons on one screen — destroys visual hierarchy.
No loading state on async actions — users click again thinking it didn't work.
Disabled buttons with no explanation of how to enable them.
Destructive actions styled as primary buttons — the same visual weight as "Save."
Button labels in ALL CAPS — harder to read and feels aggressive.
Buttons that look like links (text only) for primary actions on mobile — too easy to miss.

Checklist

Button label is an action verb describing the outcome

Maximum one primary button per screen

Loading state exists for async actions (spinner or label change)

Disabled state is visually distinct and explains why it's disabled

Destructive buttons use a secondary or danger style, not primary

Touch target is at least 44×44px on mobile

Icon-only buttons have accessible labels (aria-label or tooltip)

All required states exist: default, hover, focus, active, disabled, loading

Button contrast passes WCAG AA (4.5:1 for text)

Consistent placement of confirm/cancel across all dialogs

Research & Theory

Fitts's Law

The time to click a target increases with distance and decreases with size. Primary actions should be large and centrally positioned.

Why it's relevant

Button size and placement are not aesthetic choices — they have measurable effects on task completion speed.

Action Labeling Research (Sauro & Lewis)

Research shows that specific, descriptive button labels significantly outperform generic labels in usability testing and conversion.

Why it's relevant

"Start Free Trial" converts measurably better than "Sign Up." The label is part of the design.

Real-World Examples

Linear

Every action in Linear has a specific label. "Create Issue" not "Create." "Mark as Done" not "Done." Loading states are instant-feeling via optimistic updates.

Stripe

Payment buttons say "Pay $49.00" — the exact amount. Removes any ambiguity. Disabled states explain the required action to enable them.

GitHub

"Merge pull request" becomes "Confirm merge" on the confirmation step — the label changes to match the specific action. Destructive operations use red styling.