When does your product need a design system? And what should the first version include?

Most products do not start with a design system, and they should not. In the first weeks the goal is to find out whether the product works for anyone. But there is a point where the lack of one starts to cost real time and money, usually long before anyone says the words out loud.

This article covers what a design system actually is, the signs that your product needs one, when it is still too early, and what a useful first version contains.

What a design system actually is

A design system is the shared set of rules and parts a product is built from. It has three layers:

• Foundations, often called design tokens: colours, typography, spacing, corner radii, shadows and motion, each with a name and a single defined value.
• Components: buttons, inputs, tables, dialogs, navigation and the other building blocks, including every state they can be in.
• Guidelines: when to use which component, how to write labels and error messages, and the accessibility rules every screen has to meet.

Tokens have become a standard of their own. The W3C Design Tokens Community Group published the first stable version of its Design Tokens specification in October 2025, a shared format that design and development tools can read. That matters, because a design system is only useful if design and code use the same values.

Signs your product needs one now

• The interface is drifting. Three slightly different greys, four button styles, forms that each handle errors in their own way. Nobody decided this; it built up one feature at a time.
• Every feature starts by redrawing the basics. Designers and developers rebuild tables, filters and dialogs instead of working on the actual problem.
• More people are working on the product. A second developer, a new designer or an external team will each fill gaps with their own choices.
• A second surface is coming. A web app next to a mobile app, or a marketing site that should look like the product, needs shared foundations to feel like one brand.
• You generate screens or content with AI. Without rules, every output looks slightly different. A brand foundation and a small design system give generated work something to follow. It is the reason our deck engine for Caya produces slides that look bespoke.
• A product-wide change is on the list. Dark mode, a rebrand, white-label versions or accessibility fixes become one change to the tokens instead of a hunt through hundreds of screens.

When it is too early

If you are testing whether an idea works at all, a full design system is a distraction. A library of fifty polished components for a product that may change direction next month is money spent on the wrong question.

One habit is worth having from the very first day, though: define colours, type and spacing as named values in the code, not as values copied into every component. It costs almost nothing, and it is the difference between adding dark mode or a new brand colour in an afternoon and rewriting the interface later.

What a useful first version includes

A first design system does not need to be large. It needs to cover what your product actually uses today, and cover it properly:

• Tokens for colour, typography, spacing, radii and elevation, with names that describe their purpose (such as text-muted or surface-raised) rather than their value.
• The components your screens use now, each with all of its states: default, hover, focus, disabled, loading, error and empty.
• The patterns that repeat across the product, such as forms, tables with filters, and empty and error screens.
• Accessibility basics built in: contrast that passes, visible focus states, touch targets large enough for real fingers.
• Short usage notes, so the next person knows which component to pick and why.

Figma library or code? Both, from one source

The most common failure we see is a beautiful Figma library that the code does not follow. The designs say one thing, the product does another, and after a few months nobody trusts either.

That is why, in our app development work, colours, type and components are defined once and used in both Figma and the code, so new features look like they were always there. On new products, the system grows out of components that already exist in code, as we describe in how our product work starts in code. It stays in sync with what ships, because it is made from what ships.

What it looks like in practice

For Ankaadia, we redesigned a relocation platform across more than 150 screens and built a design system from the ground up for its development team. It includes foundations like tokens, styles and accessibility guidelines, and a component library covering every interface pattern used across the app, so implementation is faster and the interface stays consistent as the product grows.

Not every system has to be that big. For Elea, we documented the website's colours, typography, graphics, motion and components, giving the team a practical guide for future work on its web presence.

Questions to ask before you commission one

• Will the system exist in code, or only as a Figma file?
• Is it built from our real screens and use cases, or adapted from a generic kit?
• Does it cover states, errors and accessibility, or only the happy path?
• Who maintains it after handover, and how are new components added?
• Can our own developers use it without you?

A design system is not a deliverable you finish. It is the part of the product that makes every later change cheaper. If you are planning a platform or want to bring order to one that has grown, our web applications page shows how we approach product design and development together.