Button Design: Primary, Secondary, Sizes and States

Buttons translate a screen's priorities into visible actions. When every control is filled, bright, and equally large, the interface stops explaining what matters. Good button design begins with an action hierarchy and ends with states that remain recognizable during real use.

Define emphasis before drawing variants

Inventory the actions on one representative screen. Identify the action that completes the current task, the alternatives that preserve context, and any commands that remove information. Assign visual emphasis according to those relationships rather than giving every feature its own color.

Use the Contrast Checker to inspect candidate label and background pairs before polishing details. Test the actual fill, not a nearby brand swatch. An outlined button needs its text checked against the surface behind it; its border has a different visual role. Repeat the check for hover and pressed treatments when their backgrounds change.

A useful starting set is primary, secondary, and quiet. These names describe prominence, not business importance. A destructive command can be quiet in a list but prominent inside a confirmation dialog. Consult the WAI button pattern for expected interaction behavior while keeping this visual exercise focused on clarity.

Size buttons around labels and context

Use horizontal padding rather than fixed widths for ordinary text buttons. A starting point might be 16 pixels on either side with a 44-pixel minimum height, then adjust for your interface. These values are design choices, not a claim that every button must have identical dimensions.

Maintain a small number of size variants with a specific purpose. A compact table action and a form submission button can differ, but arbitrary one-pixel adjustments across screens create unnecessary inconsistency. Keep label size readable; compactness should come primarily from surrounding space and context, not from tiny text.

Prefer verbs that name the outcome: Download report, Save changes, or Add member. Generic labels such as Continue can work when the next step is unmistakable, but they are weak in an isolated dialog. Let labels expand for translation. Two short English words are not a reliable width specification.

For icon-and-label buttons, choose a stable gap and align the icon optically with the text. An icon-only control needs an accessible name and a recognizable purpose. Do not use an unfamiliar symbol simply to fit another command into an overcrowded toolbar.

Implement stable geometry across variants

Reserve border space in every variant so changing emphasis does not alter dimensions. Separate the visual style from the underlying element: use a button for actions and a link for navigation, even when both receive similar presentation. MDN's button reference covers native behavior and attributes.

.button {
display: inline-flex;
align-items: center;
justify-content: center;
gap: .5rem;
min-block-size: 2.75rem;
padding: .625rem 1rem;
border: 1px solid transparent;
border-radius: .5rem;
font: inherit;
font-weight: 600;
}
.button--primary { background: #1743a5; color: white; }
.button--secondary {
background: white;
color: #17315e;
border-color: #8090a8;
}
.button:focus-visible {
outline: 3px solid #17315e;
outline-offset: 3px;
}

This sketch intentionally omits application state logic. A loading flag, submit handler, and disabled condition must come from the component's behavior. Avoid treating CSS alone as a complete button implementation.

Use the Flexbox Playground to compare icon alignment and wrapping in a realistic action group. Keep a single button's contents together where practical, but allow neighboring buttons to wrap instead of overflowing their container.

Design the complete state set

Show default, hover, pressed, focused, disabled, and pending examples side by side. Focus visibility must remain distinct from hover because keyboard users need an indicator even without a pointer. Keep the indicator outside clipping containers or provide enough internal room for it.

A pending state should explain that the action was received. Preserve the button's width when replacing its label or adding a progress indicator. If the label changes from Save changes to Saving, reserve enough space for both or retain the original label with an adjacent indicator. Prevent duplicate submissions in application logic rather than assuming a dimmed appearance will do so.

Disabled styling should look unavailable, but avoid making nearby instructions unreadable. If people need to understand why an action is unavailable, provide that explanation outside the disabled control. Tooltips attached only to disabled buttons are an unreliable place for essential guidance.

For destructive actions, combine precise language with appropriate emphasis. Delete workspace is clearer than Confirm. Avoid making a destructive button the visually dominant action in an everyday toolbar unless deletion is genuinely the screen's current purpose.

Review groups instead of isolated specimens

A button gallery can hide problems that appear in a real footer. Place the variants beside forms, cards, and table rows. Compare a single primary action with a group containing Back, Save draft, and Publish. The correct hierarchy is contextual, not an intrinsic property of a blue rectangle.

Test long labels, enlarged text, and narrow containers. If a group stacks, preserve its logical order and make sure the dominant action remains easy to associate with the current content. Full-width mobile buttons can work, but they should not stretch into oversized bars on every screen.

Check that all states remain distinguishable without subtle shadows. The WCAG quick reference is useful when reviewing relevant contrast, focus, and target-size requirements; do not equate a single color check with a complete accessibility review.

Finish by recording when each variant is appropriate and showing at least one misuse. Browse the broader UI Design guides for surrounding component decisions, but keep the button rules compact enough that a developer can apply them without interpreting a mood board.

Compare action labels across the entire screen before finalizing the component. If Save appears in both a card and the page footer, make their scopes explicit through placement or wording. A person should be able to predict whether a command affects one item or the complete page. Also inspect adjacent destructive and routine actions. Give them enough separation that a hurried pointer movement does not make removal feel like the natural continuation of editing. This separation should remain visible when the action group wraps into multiple rows.

Key takeaways

• Use emphasis to communicate the current task's action hierarchy.
• Size around content rather than short English labels.
• Preserve stable dimensions across borders and pending states.
• Design focus, disabled, destructive, and loading treatments explicitly.
• Evaluate buttons in real action groups, not only in isolation.