Design systems have been one of the most discussed topics of recent years. Every team wants one, and most teams stop using theirs six months later. The problem is not the system itself but its timing, and what gets called a system.

What a design system is and is not

A tidy Figma file is not a design system. A design system is an agreement that the button the designer draws and the button the developer codes are the same thing. Colours, type sizes, spacing and components live in both design and code under the same name and the same value. Without that match, all you have is a nice style guide.

When is it too early?

If the product is still finding out what it is, building a comprehensive system slows the team down. Documenting components while flows change every week produces work that will be thrown away the week after. At this stage you need three small decisions:

  • A limited colour palette and what each colour is for,
  • A type scale of four or five sizes,
  • A single spacing unit and its multiples.

These three are usually enough for a first release to look consistent, and they take a day to set up.

When does it pay off?

We use a simple test: if you are drawing or coding the same component for the third time, it is time to build the system. These signs say the same thing:

  • A second platform is being added (mobile next to web, for example).
  • New designers or developers are joining the team.
  • You have started to see two different button styles in two places on the same screen.
  • A small visual change means touching dozens of files.

From this point the system stops being a cost. Designing and building a new screen gets shorter, pixel debates in design reviews fade, and accessibility rules are applied once per component.

What keeps a system alive

The most common problem we see is an up-to-date design file and outdated code. To prevent it we manage the system from inside the code: colour and spacing values come from a single source, components live in a documented library, and when a component changes the change reaches design and code together. The system has an owner; a system without one falls apart within months.

In short

A design system is not a prestige project but a productivity tool. Build it too early and it is a burden; too late and debt piles up. The right moment is when repetition begins.