Button design for websites: roles, states and sizes as one system
Buttons look simple until a site has twenty of them. Treat them as a small system: two or three roles that look clearly different, five states each role handles, and one or two sizes. Decide those once and every new button on the site is already designed.
Roles: primary, secondary, tertiary
Good button design for websites starts with roles. A role tells the visitor how important an action is. Most websites need three at most, and the difference between them should be visible at a glance, not a shade of grey.
| Role | Typical style | Use for | How many per view |
|---|---|---|---|
| Primary | Solid fill in the action colour, contrasting label | The main thing to do: Book, Buy, Send | One |
| Secondary | Outline in the text or action colour, transparent fill | A real alternative: See the menu, View pricing | One or two |
| Tertiary | Text link style, perhaps with an arrow | Low-stakes actions: Read more, Cancel | As needed |
| Destructive | Red fill or red text, only where it applies | Delete, Remove, in dashboards and account areas | Rare on marketing sites |
The five states every button needs
- Default
- What it looks like at rest. It must look pressable: a fill, a border or an underline.
- Hover
- A clear change of fill, border or underline for mouse users. Darkening or lightening the fill by about 8 to 12 percent is a reliable choice. Fading the whole button with opacity looks washed out and unresponsive.
- Focus
- What keyboard users see when they tab to it. A 2px to 3px outline in a contrasting colour with an offset of 2px is clear on almost any background. Use
:focus-visibleso the ring doesn't flash on mouse clicks, and never remove outlines without a replacement, since visible focus is a WCAG requirement. - Pressed
- A brief response to the click itself: a slightly darker fill or a 1px shift down. It tells people the press registered.
- Disabled
- Used sparingly. A greyed button gives no reason why it can't be pressed. Often better: keep it enabled and explain what's missing when it's pressed, such as which form field needs filling.
Add a loading state for anything that waits on a server, like a form submission: change the label to “Sending…” and prevent double presses.
Sizes and spacing
- Height: 44px to 48px for main buttons. WCAG 2.2 asks for targets of at least 24px at level AA; 44px is a comfortable size for thumbs.
- Padding: around 16px to 32px either side, so the label doesn't touch the edges.
- Label size: 15px to 17px, medium or semibold weight, in sentence case. All-caps labels with wide tracking can work in some styles but read more slowly.
- Spacing between buttons: at least 8px to 12px, so a thumb doesn't hit the wrong one.
- Full width on phones for the main action of a form; side by side on larger screens.
Shape follows role
A common sign of an unplanned interface is one radius and one shadow on everything: buttons, cards, inputs and images all at the same 8px corner. Give shape a job instead. Buttons can be pill-shaped or square across the whole site while cards have their own radius and images stay square. The consistency within each role, and the difference between roles, helps people tell a button from a box at a glance. See border radius in UI design.
Buttons, links and accessibility
- Buttons do, links go. Use
buttonfor actions on the page andafor moving to another page, even when they look identical. - Contrast: the label needs 4.5:1 against the fill; an outlined button's border needs 3:1 against the background.
- Don't rely on colour alone to show state; pair it with a shape or outline change.
- Icon-only buttons need an accessible name, via visible text or
aria-label. - Respect reduced motion for any animated hover or press effect.
Buttons in Anticode's design systems
Each of Anticode's design systems sets radius by role, so buttons, cards and inputs have their own shapes: pill-shaped buttons in Editorial, Playful and Organic, square ones in Swiss, Brutalist and Luxury, and a small radius in Technical. Each system has one action colour for primary buttons, chosen from eight in the visual editor. Luxury uses outlined buttons that fill on hover; Brutalist buttons press into their hard shadow.
Two checks cover the states. The design gate blocks publishing a page without visible keyboard focus or without support for reduced motion, and the Critic flags hover states that only fade opacity. Neither judges whether your labels are clear, so read them aloud; call to action button design covers wording.
Questions people ask
What states does a button need?
Default, hover, focus, pressed and disabled, plus loading for anything that waits on a server. Focus matters most for accessibility.
Should disabled buttons be greyed out?
If you use a disabled state, yes, but use it sparingly. A button that stays enabled and explains what's missing is often clearer than a grey one with no reason.
How rounded should buttons be?
Any radius works if it's consistent and different from cards and inputs. Pill shapes feel friendly; square corners feel precise.