← Projects

What does a well designed button look like?

I recently worked on an accessibility review of a design for a new web product that we're building at work. After a long discussion about whether something should be a link or a button, and if a button was the right choice for the given use case, I left the meeting with a newfound curiosity in buttons. They are one of the smallest UI elements on the web, and yet they are the primary mechanism through which users do things — they purchase, submit, confirm, delete, navigate, and create. This post is everything I learned, put into a practical guide primarily for me but also for anyone else designing buttons in a large design system.

To button or not to button?

Before designing a button, ask whether a button is actually the right element. A button triggers an action — submitting a form, logging in, deleting a record. A link navigates you somewhere. Use the <button> tag for actions and the <a> tag for navigation, so screen readers can correctly identify what a user is interacting with. Avoid using a <div> or <span> that looks like a button but isn't. It may look right visually, but screen readers will announce it incorrectly, and keyboard users won't be able to interact with it as expected.

Try it — same look, different semantics:

<button> — triggers an action

Go to help <a> — navigates somewhere

Looks like a button <span> styled as button — poor semantics, no native focus

Interact with one above. Use Tab to move focus and see how keyboard and screen readers treat each.

Designing different types of buttons for different use cases

Most design systems organize buttons into at least three tiers, each with a specific role.

Primary button — The most prominent action on a screen — the thing you most want the user to do. "Buy Now" or "Create account" are classic examples. There should almost always be only one primary button visible at a time. Use high contrast, solid fill, and strong visual weight to make it unmistakable.
Secondary buttons — Represent actions that are necessary but not the main goal, like "Cancel," "Save draft," or "Learn more." They should be visually present without competing with the primary. An outlined or lower-contrast style is the common pattern.
Tertiary buttons — For low-priority or optional actions, like "Skip" or "Remind me later." They live at the bottom of the visual hierarchy, typically styled as underlined text with no border or background.
Destructive buttons — Their own category entirely. Any action that deletes data, removes a user, or can't be undone needs a distinct visual treatment (usually red) and often a confirmation step. Don't fold these into tertiary.

Try each type — notice the visual hierarchy:

Primary

Secondary

Tertiary

Destructive

Click or focus a button to see its role in the hierarchy.

Designing different states for a button

Every interactive button needs to be designed for six distinct moments in its lifecycle:

Default state — How the button looks at rest. This is your baseline.
Active state — Fires in the brief moment a button is being pressed, providing satisfying tactile feedback.
Hover state — Gives users visual feedback that the element is interactive as their cursor moves over it.
Loading state — Appears after the user has clicked and the system is processing. A spinner confirms something is happening and prevents the user from clicking again and triggering duplicate requests.
Disabled state — Communicates that an action is currently unavailable. It should appear visually muted and not respond to interaction.
Focus state — Critically important for keyboard and assistive technology users. It is the visible ring that shows which element is currently selected. Removing the focus ring is a shockingly common practice done in the name of aesthetics, but it is a WCAG violation and makes your product unusable for keyboard-only users.

All six states shown separately:

Default — at rest

Hover — cursor over it

Focus — keyboard selected

Active — being pressed

Loading — processing

Disabled — unavailable

Design considerations for creating a good button

Color

Use color to indicate hierarchy level of the button while also ensuring readability of the button labels. For normal-weight text on a button, the minimum contrast ratio is 4.5:1 for WCAG AA compliance. For large or bold text, the minimum drops to 3:1.

Shape

Pick one shape that fits your product's personality and apply it everywhere. Rounded circles or squares are the most common shapes, and you should try to use them as often as possible. Avoid using irregular and unexpected shapes unless absolutely necessary, since they may affect the discoverability of your buttons.

Size

A button's size should be relative to the window size it is a part of. Ensure that buttons have enough padding, and are large enough to click on with a finger rather than just with a mouse. Aim for at least a 44×44px touch target in buttons to make them accessible and clickable.

Copy

Use concise wording that fits in one line and avoid wrapping text. Ensure that the text informs the users about what will happen after the button is clicked.

Affordance

The button should look like something you can press. If the user has to hover over it to figure out if it does anything, something has gone wrong. The button should look "clicky" even before the user interacts with it.

Visual consistency

Visual consistency is what makes a bunch of individual buttons feel like a system. Same shape, same spacing, same color rules, everywhere. When users learn what a button looks like in one part of your product, that knowledge should carry over to every other part.

Delight

Once you've ticked all the basics, don't forget to add some fun to buttons! Fun buttons can add delight to users' workflows, and have the potential to lead to positive outcomes.

This was a fun deep dive! I learned about all the deliberate decisions that go into designing the simplest, but most powerful UI element online, and am excited to design more buttons in the future!