Eleven Different Buttons
Nobody decided to have eleven button styles. They accumulated, one reasonable decision at a time — which is exactly how every inconsistent product got that way.
Someone audits a mature product and comes back with the numbers: eleven button styles, six shades of grey that were meant to be one, four modal dialogues with four different paddings, three date formats, two words for the same object.
Nobody chose any of this. Every single instance was a reasonable local decision by a competent person under time pressure, and there were eleven of them across three years. Inconsistency is not a failure of taste. It's the default state of anything without a system.
What a design system actually is
It isn't a folder of components, though that's the visible part. A working system has four layers plus one thing that isn't a layer at all:
Tokens — the named values everything else is built from: spacing scale, type scale, colours, radii, borders, motion durations. Salesforce's Lightning team popularised the term, and the point is naming: space-md and text-secondary survive a redesign, 16px and #8a8a8a don't.
Primitives — the smallest usable components: button, input, checkbox, label, icon. Brad Frost's Atomic Design offered the vocabulary for thinking about composition here — atoms combining into molecules, molecules into organisms — and the useful part is the habit of asking what level a thing belongs to.
Patterns — recurring compositions: a form row, an empty state, a confirmation dialogue, a data table, a page header.
Guidelines — when to use each thing, and crucially when not to.
And the thing that isn't a layer: a process. Who owns it, how something gets added, how something gets deprecated, how teams request changes. A system without that is a snapshot that starts rotting the day it ships.
What it's actually for
Three benefits are usually listed, and the third is the one that matters most day to day.
Learnability. This is the user-facing argument and it's the strongest. If a pattern is consistent, a person learns it once and it transfers to every other screen. Every inconsistency forces a fresh act of learning at the exact moment they were trying to do something else.
Quality by default. Accessibility, focus states, keyboard handling, loading states, contrast — solved once inside the component, inherited by every future screen for free. This is the most economically persuasive argument for accessibility work there is.
Attention. The layout article said constraints delete the part that was never design. A system does that at product scale: you stop re-deciding what a button looks like and spend the attention on whether this screen solves the problem. A designer with a system makes fewer decisions and better ones.
A system doesn't make you faster at drawing. It stops you drawing the same thing again.
Components own their states
The most common gap in a young design system: components that exist in one state.
A real button component includes default, hover, focus, active, disabled and loading. A real input includes empty, filled, focused, error, disabled and read-only. A real table includes empty, loading, one row, many rows, and too many to show.
If the states live in the component, the flows-and-states article's checklist gets satisfied automatically, everywhere. If they don't, every designer re-invents an error state per screen, and you get eleven of those too.
When you don't need one
Systems have a maintenance cost, and it's real.
For a one-off landing page, a two-week prototype or a three-screen side project, a design system is overhead you'll never recoup. Use sensible defaults, a spacing scale and one component library off the shelf.
And there's a worse case than having no system: having one nobody maintains. An out-of-date system lies. People copy patterns that have been superseded, half the components don't match production, and everyone quietly starts detaching and forking — at which point you're paying the maintenance cost and getting the inconsistency anyway.
Grow it, don't design it
The failure mode of ambitious teams is building the system first, in the abstract, before enough real screens exist. You end up with beautifully specified components nobody needed and none of the awkward ones everybody does.
The reliable method is extraction:
The rule of three. The first time you need something, build it inline. The second time, copy it and note the duplication. The third time, make it a component. By then you know what actually varies, which is the only way to design the right props.
Document intent, not just appearance. Screenshots and specs say what it looks like. The useful part is: what problem does it solve, when do you use it, when should you not, and what should you use instead. That "when not to" section is what separates a system people follow from one they route around.
Provide an escape hatch, and watch it. Too rigid and people fork silently; too loose and everything is configurable and nothing is consistent. Let people override, but track which overrides happen repeatedly — a repeated override is a missing component telling you it exists.
Deprecate out loud. Mark old components as deprecated with a named replacement and a date. Systems die from accumulation, not from change.
Consistency has limits
Nielsen's fourth heuristic covers consistency and standards, and it's worth reading carefully: it means people shouldn't have to wonder whether different words or actions mean the same thing. It doesn't mean everything must look identical forever.
Two honest caveats:
A consistent bad pattern is bad everywhere. Consistency multiplies whatever you have. That's an argument for testing patterns before they enter the system, not against systems.
Break consistency when the task genuinely differs. A destructive action should not look like every other action; an expert-only bulk tool doesn't need the spacing of a marketing page. The rule is: deviate deliberately, document why, and don't let the deviation quietly become a twelfth button style.
In practice
Audit one product for duplicates. Count your button styles, greys, border radii and modal paddings. The number is always worse than expected, and the count is what gets a system approved.
Write your tokens first. Spacing, type scale, colours, radii. A list in a file. Everything else can wait.
Add missing states to one component. Take your button or input and design every state it lacks. That single component then fixes dozens of screens.
Apply the rule of three. Look for the pattern you've now built three times and extract it this week.
Write one "when not to use this." Pick your most misused component and add the section. It's the highest-value paragraph in any system's documentation.
Track overrides for a month. Every repeated override is a component you haven't built yet.
Check yourself
Close the article and answer in your own words:
- Why is inconsistency the default rather than a failure of care?
- Name the four layers of a design system and the thing that isn't a layer.
- Why are named tokens better than raw values?
- Which of the three benefits matters most to a user, and which to a designer's day?
- What makes an unmaintained design system worse than no system?
- What is the rule of three and why does it produce better components?
- When is deviating from the system correct, and what must accompany it?
In short
- Eleven button styles are the accumulation of eleven reasonable local decisions. Inconsistency is the default without a system.
- A system is tokens, primitives, patterns, guidelines — plus a process and an owner, without which it starts rotting immediately.
- Benefits: users learn a pattern once, quality like accessibility is inherited for free, and designers stop spending attention on settled questions.
- Components must own all their states, or every screen re-invents its own error and empty states.
- Small or short-lived projects don't need one; an unmaintained system is worse than none because it lies.
- Extract the system from real screens by the rule of three, document when not to use each thing, and provide a tracked escape hatch.
- Consistency multiplies whatever you have, so test patterns before adopting them, and deviate deliberately and documented when the task truly differs.