Design Systems: When They Pay Off and When They're Overhead
A design system is a shared library of components, patterns, and rules, maintained as a product in its own right. It exists to stop teams rebuilding the same button forty times in forty slightly different ways.
Which tells you when it is worth having: when there are enough people building enough things that the divergence is costing you more than the maintenance would. For distributed teams, employee monitoring software can add operational context to the same question by showing where time and hand-offs are actually being lost.
Below that threshold, it is overhead with good intentions.
What one actually contains
Design tokens. The primitives — colour, spacing, type scale, border radius, shadow — defined once as named values and referenced everywhere. Change the token, and every use updates.
Components. Buttons, inputs, cards, modals, tables, navigation. Each with its states: default, hover, focus, active, disabled, loading, error, empty. A useful archive of related web practice is available at A List Apart.
Patterns. How components combine for recurring jobs — forms, filtering, pagination, onboarding.
Documentation. When to use what, and what not to do.
Code implementation. The components as real code, matching the design library. A system that exists only in Figma is a style guide.
Governance. Who maintains it, how changes are proposed, how versions are released.
That last item is what makes it a system rather than a folder. Without governance, a component library drifts within a year. Performance requirements can be checked against the web.dev Core Web Vitals guidance.
When it pays off
Multiple product surfaces. A web app, a marketing site, and a mobile app that should look like one company.
Multiple teams shipping in parallel. The cost of divergence scales with the number of people who can create a new button.
Frequent iteration. If you are shipping weekly, the compounding time saved on component work is real.
Long-lived products. Systems repay their setup cost over years, not months.
Rebrands or theming ahead. With tokens, a colour change is a token update. Without them, it is a search through every stylesheet.
Accessibility requirements. Building accessibility correctly once into a component library is far cheaper than auditing every screen. This is one of the strongest arguments and the least mentioned.
When it is overhead
A single marketing site. A well-organised stylesheet with CSS custom properties is sufficient and takes an afternoon.
One or two people building. Consistency is achievable by memory at that scale.
Before product-market fit. Building infrastructure for a product whose shape will change three times is premature.
Short-lived projects. A campaign site does not need governance.
No maintenance capacity. An unmaintained design system is worse than none — teams work around it, and the drift is now invisible because everyone assumes the system is being followed.
The middle path
Most businesses sit between "nothing" and "a design system," and the middle options are underrated.
Design tokens alone. Colour, spacing, and type defined as CSS custom properties, referenced throughout. Cheap, immediately useful, and the foundation if you later build more.
A component library without governance. Reusable components in code and in Figma, no formal process. Works well for small teams.
A UI kit. A Figma library of styles and components with no code counterpart. Useful when design consistency is the problem and implementation is handled by one developer.
Adopting an existing system. Open-source systems and headless component libraries give you accessible, tested components without building them. Theming an existing system is a fraction of the cost of authoring one, and for most businesses it is the right answer.
That last option deserves more consideration than it gets. The reasons to build your own are a genuinely distinctive interface language or requirements no existing system meets — not the appeal of having one.
What it costs
Initial build: for a small system covering perhaps twenty components in design and code, expect a few weeks of dedicated work. Larger systems run into months.
Ongoing: this is what gets underestimated. Someone must maintain components, review contributions, manage versions, update documentation, and handle migrations. Without allocated time, decay begins immediately.
A useful rule: if you cannot name the person responsible for maintaining it, do not build one.
Common failure modes
Built and abandoned. Shipped with enthusiasm, unmaintained after three months, ignored within a year.
Too rigid. A system that cannot accommodate legitimate new requirements gets bypassed. Provide an escape route and a path for new components to enter.
Design and code out of sync. The Figma library and the coded components diverge, and nobody knows which is authoritative. Tokens shared across both help; discipline helps more.
Documentation as an afterthought. Undocumented components get misused or rebuilt.
Built too early. Infrastructure for a product that has not settled.
How to start, if you should
- Audit what exists. Screenshot every button, input, and card currently in your product. The redundancy is usually startling and makes the case on its own.
- Define tokens first. Colour, spacing, type. Immediate value, minimal effort.
- Build the five most-used components, with all states, accessible by default.
- Document as you go, briefly.
- Assign an owner before adding anything else.
- Expand from real demand, not from a list of components other systems have.
Starting with tokens and five components gives you most of the practical benefit for a small fraction of the cost, and it tells you within a couple of months whether the full system is justified.
Помогаем выбрать подходящий уровень — от токенов до полноценной системы. Услуги веб-дизайна. .