When a design system is worth building — and when it is overhead

Design systems have become a default recommendation, which means plenty of organisations are building them before they have the problem a system solves. They are infrastructure, and infrastructure has carrying costs.

The problem a system actually solves

Not beauty, and not consistency for its own sake. A system solves coordination: multiple people producing work in parallel who need to arrive at compatible results without constantly consulting each other.

Signals you are ready

• More than one designer, or designers plus engineers building UI
• The same component being rebuilt slightly differently each time
• Arguments about spacing and colour recurring in every review
• Multiple products or sub-brands that must feel related
• Onboarding a new designer taking weeks of pattern archaeology

Signals you are not

• One designer producing everything
• A product still changing direction fundamentally each quarter
• No engineering capacity to consume the system
• Nobody with clear ownership of maintaining it

An unmaintained design system is worse than none. It becomes a source of confidently wrong answers.

Start smaller than you think

Tokens first: colour, type scale, spacing. Then the five components you genuinely use everywhere. Documentation of decisions, not aspirations. A system that covers eighty per cent of real cases and is actually maintained beats an exhaustive one nobody updates.

Ownership is the whole game

The systems that survive have a named owner with allocated time. The ones that rot were everybody's responsibility. Decide this before you build, not after.