A design system is the set of decisions a team stops re-making. Colour, type, spacing, and the components built from them, written down once so the fortieth screen costs less than the fourth rather than more.
Most systems fail the same way. They are built as a Figma library, they are never built in code, and within a few months production and the file disagree. At that point the system is not a source of truth — it is a second thing to maintain.
What actually belongs in a design system?
Tokens, components, and the reasoning. Tokens are the primitives — colour, type scale, spacing, radius, motion. Components are what you build from them. The reasoning is what stops the next person from adding a fourth button variant because they could not tell which of the three to use.
The reasoning is the part that gets skipped, and it is the part that decides whether the system survives. Documentation that only says how to use a component is a catalogue. Documentation that says when not to use it is a system. The longer version is in what a design system is for.
What we deliver
- Design tokens — colour, type, space, radius, motion — as the single source
- A component set that exists in Figma and in code, not one or the other
- Documentation covering when not to use a component, not only how
- RTL and bilingual behaviour defined at the token layer, not per screen
- A named owner and a rule for how the system changes after handover
Do we need a design system at all?
Often not. A system pays for itself when several people build screens in parallel over a long enough period. One product, one designer, one engineer, six weeks — a system is overhead you will feel immediately and benefit from never.
We will tell you when the answer is no. A system built too early is a set of decisions made before you knew enough to make them, and unpicking those costs more than not having had them.
Can you work inside the system we already have?
Yes. There are three honest options — work inside yours, repair yours, or replace it — and we will tell you which one your system actually needs rather than defaulting to the one that bills best.
Replacing a system is the expensive answer and it is usually the wrong one. A system that is inconsistent but adopted is worth more than a clean one nobody has migrated to.
What does "in code, not only in Figma" mean?
It means the tokens exist as real variables the product imports, so changing one changes the product rather than changing a picture of it. A Figma library alone describes an intention. Code is the only version users ever see.
This is straightforward for us because the engineers are in the same studio, which is also why we include the system in a product design or website project instead of quoting it separately. It is not an upsell. It is how the work gets built.
What happens to the system after handover?
It needs one owner on your side and a rule for how it changes. Systems do not decay because they were badly built. They decay because nobody was responsible for saying no to the fourth button variant.
We hand over with that named, and we stay for the next release if you want us to. How engagements run covers the shapes that can take.