Design systems that survive contact with reality

Most design systems do not fail because the components were poorly designed. They fail because six months in, three teams have quietly forked the button, nobody can remember what the spacing scale means, and the Figma file has drifted from what ships. The system did not lose an argument. It lost to entropy.

Start smaller than feels right

The instinct is to build the full component library before anyone uses it. This is almost always a mistake. A system with eight components that every team actually uses beats one with sixty that people work around. Ship the primitives — colour, spacing, typography — and let real product work tell you what the next component should be.

Tokens before components

Components are opinions about layout. Tokens are agreements about vocabulary. Get the vocabulary right and the opinions become much easier to change later. A team that agrees on what space-4 means can redesign a card in an afternoon. A team that has hardcoded pixel values everywhere cannot.

Make the right thing the easy thing

If using the system is more work than not using it, people will not use it, and no amount of documentation or process will fix that. This is an ergonomics problem, not a discipline problem:

• Sensible defaults, so the common case needs no configuration
• Escape hatches, so the uncommon case does not require a fork
• Real examples in the docs, not just prop tables
• Fast feedback when something is used incorrectly

Budget for maintenance from day one

A design system is a product with internal customers, and it needs the same things any product needs — an owner, a roadmap, a way to file bugs, and someone who answers questions. Systems treated as a one-time project rather than an ongoing commitment reliably rot within a year.

None of this is glamorous. That is rather the point.