Button Design

Button design is the design of what a button looks like, what it says, what it does in every state, and how a person can tell which of several is the one that matters. It is the most repeated component in almost every product, which makes it the place where inconsistency is most visible and most expensive.

A button performs an action. That distinguishes it from a link, which navigates, and the distinction is not cosmetic: links can be opened in a new tab, copied and announced correctly by a screen reader, and buttons cannot.

Buttons and links

The test is whether a URL could describe the result. If it could, it is a link, whatever it looks like. Styling a link like a button is a visual decision and perfectly fine; building a button that navigates removes behaviour users rely on.

Hierarchy: one primary, and the discipline to keep it

Four levels cover almost everything.

Primary. The action the screen exists for. One per screen. When a screen has three, none of them is primary and the user does the work of deciding.

Secondary. Real alternatives, visible but quieter.

Tertiary or ghost. Low-frequency actions that must be available without competing.

Destructive. Anything that removes or cannot be undone, styled so it cannot be mistaken for the primary.

The failure mode is inflation. A team needs something to stand out, promotes it, and repeats that until the screen is full of emphasis. The fix is almost always demotion rather than a new style, and the test is simple: squint at the screen and see whether one thing survives.

Labels

Verb plus object. Send invitation. Delete workspace. Save changes. The label should make sense read alone, because that is how a screen reader announces it and how a hurried person reads it.

The user's words, not the system's. Submit describes what happens to the data, not what the person is doing.

Never OK and Cancel on a consequential dialog. "Delete this workspace? [Cancel] [Delete workspace]" can be answered without reading the question. "OK" cannot.

Avoid Yes and No against a negatively phrased question. "Don't save changes?" with Yes and No is a puzzle.

Keep the length honest. A label that needs eight words is usually a sign the action is doing too much.

States, and the two that get skipped

Every button needs default, hover, focus, active, disabled and loading. Two of those are routinely missing.

Focus. Removing the focus ring because it clashes with the design strands everybody who navigates by keyboard. It can be restyled; it cannot be deleted.

Loading. A button that does nothing visible for half a second gets pressed twice, and in a product without idempotent requests that means two invitations, two charges, two records. The press state and an immediate transition to loading are the cheapest defect fix in most interfaces. See interaction design.

Disabled deserves particular care. A disabled button with no explanation tells somebody they cannot proceed and nothing about why. Either explain the condition nearby, or allow the click and explain on attempt.

Buttons in B2B interfaces

Toolbars and row actions multiply everything. A table with per-row actions renders the same button hundreds of times, so anything expensive in one costs a hundred times as much, including the animation.

Bulk actions introduce a partial-failure state. Forty rows selected, six of which cannot be processed. The button needs an answer for that, and it is almost never designed.

Permissions change what exists. The same screen shows different buttons to an admin, a member and a viewer. Hiding an action a person cannot take is usually kinder than disabling it, unless discovering that the capability exists is the point.

Destructive actions need friction proportional to the damage. Deleting one row and deleting a workspace should not feel the same. Confirmation dialogs are overused for the trivial and underused for the irreversible, and undo beats confirmation wherever it is technically possible.

Accessibility, which is measurable

Under WCAG 2.2 at Level AA, button text needs a contrast ratio of at least 4.5:1 against the fill, and the button itself needs at least 3:1 against what surrounds it. Outline and ghost buttons fail the second most often, because a pale border on a pale background is a common aesthetic and a straightforward failure.

Beyond contrast: a target large enough to hit reliably, a visible focus indicator, a label that is not conveyed by icon alone, and an icon-only button that carries an accessible name.

In practice

A product accumulates seven button styles over two years.

The history explains it. Each was added by a team that needed something to stand out on a screen where the existing primary was already used for something else. No individual decision was wrong, and the result is that emphasis carries no information: users cannot predict which button is the important one, because on any given screen it depends who built it.

Collapsing to four styles is the small half of the work. The larger half is going screen by screen and deciding which single action is primary, which is a product conversation rather than a design one, and it is the conversation that adding a new style was avoiding.

Where teams get it wrong

• Several primaries per screen. Emphasis that does not distinguish anything.
• A button that navigates. Breaks opening in a new tab, copying the address and screen-reader behaviour.
• No loading state. The double click, and the double record behind it.
• Removing the focus ring. Fine visually, and it strands everyone not using a mouse.
• OK and Cancel on a destructive dialog. Answerable without reading the question.
• Disabled with no reason. A refusal without an explanation.