All writing

UI Design · Components

Designing a Button System: Primary, Secondary and the Trap of Too Many Variants

Every button variant added past the fourth or fifth one is a variant nobody, including the design team, will use consistently.

Jaymin Maheta 6 min read
Share:
Button variants shown side by side in a design system

A button's whole job is answering one question fast

A user glancing at a screen needs to instantly know: which button is the main thing to do here, and which are secondary options. A button system with too many visually distinct variants — solid, outline, ghost, text, tonal, each in three colors — destroys that instant read, because nothing stands out when everything looks slightly different.

The goal isn't visual variety. It's a small, learnable vocabulary that tells users "do this" versus "or this, if you'd rather" at a glance, every time.

A system that stays legible

Three variants cover almost everything

Primary (solid, one per view), secondary (outline or tonal), and tertiary/text (for the lowest-emphasis actions). Most products never genuinely need a fourth.

One primary button per view, enforced

Two solid primary buttons on the same screen forces the user to guess which one actually matters. If two actions both feel primary, that's a sign the screen needs rethinking, not two primary buttons.

Destructive is a modifier, not a fourth variant

A red "Delete" button is still structurally a primary or secondary button — just with a danger color token applied. Keep it in the same size/shape system rather than inventing a separate style.

Size variants track density, not decoration

Small, medium, large sizes exist to fit different layout densities (a table row action vs. a page-level CTA) — not as extra visual flavors to mix freely within the same context.

Disabled state needs to look genuinely disabled

A disabled button that's only slightly lighter than the active one gets clicked anyway, and the user assumes it's broken. Contrast the disabled state clearly enough that "can't click this" is obvious at a glance.

Loading state replaces the label, doesn't hide it awkwardly

A spinner that shrinks the button or shifts surrounding layout creates jank on every click. Fix the button's width and swap only the internal content between label and spinner.

Every new variant is a decision users have to relearn

Treat a request for a new button variant with real skepticism. Each addition to the button system is a new visual pattern users need to internalize, and a new decision every designer building a new screen has to make correctly. Push back and ask whether the existing primary/secondary/tertiary set, combined with color tokens and size, can express the need — it almost always can, and the system stays legible because it stayed small.

The takeaway

Three button variants — primary, secondary, tertiary — combined with color tokens and size modifiers cover almost every real need. One primary button per view, a clearly distinct disabled state, and a loading state that doesn't shift layout. Resist adding a fourth variant; every addition is a pattern users and designers both have to relearn.

Let's talk about your product