Design systems have a reputation problem. Small teams hear the term and picture a two-year programme with a dedicated staff of five. In practice, a system that fits on two Figma pages and one code package already removes most of the daily friction.
Start with decisions, not components
A design system is a set of decisions you stop making again. Which spacing values exist, which type sizes exist, what a primary button looks like when disabled. Write those down before you draw anything. The value comes from the constraint, not from the component count. A team of three designers with a fixed spacing scale produces more coherent work than a team of ten with unlimited freedom, because the disagreements move from pixels to structure.
The minimum that works
- A spacing scale of six to eight steps, based on a 4 or 8 pixel unit.
- A type scale with five sizes and two weights, defined with line height and letter spacing.
- A colour set with brand, neutral, and semantic values, each checked for AA contrast on its intended background.
- A radius and elevation scale with three steps each.
- Ten to fifteen components: button, input, select, checkbox, card, tag, navigation, footer, modal, table, alert.
- One documented rule for focus, one for disabled, one for loading.
- A single page of writing guidance: sentence case in buttons, no exclamation marks, formal address in German.
That is roughly six to ten days of work, or 5,000 to 9,000 EUR. In the second project using it, design time drops by 30 to 40 percent, and the handover conversations that used to consume a week largely disappear.
Tokens are the bridge to code
Define values once as tokens in Figma variables and export them as CSS custom properties or a Tailwind theme. When the brand colour changes, it changes in one place and reaches every screen and every component. Without tokens, a design system is a picture of consistency rather than an instrument of it. Name tokens by purpose rather than by appearance: surface-raised and text-muted survive a rebrand, while grey-200 and blue-500 have to be renamed the moment the palette shifts.
A design system nobody maintains becomes documentation of how the product used to look.
Document states, not just appearance
Most handover disputes are about states nobody drew. Every interactive component needs default, hover, focus, active, disabled, loading and error. Every data component needs empty, one item, many items, and too-long content. Drawing these once is faster than answering the same question in four projects. Pay particular attention to the empty state: it is the first thing a new user sees and the last thing anyone designs.
Governance for a team of three
- One named owner who approves additions, with a substitute.
- A rule that a pattern enters the system only after it has been used twice.
- A monthly thirty-minute review of proposed changes.
- A changelog with dates, so developers know what moved and why.
Know when to stop
Not everything belongs in the system. One-off marketing pages, campaign layouts and experiments should be free to break the rules. The system exists to make the repetitive 80 percent effortless, so the remaining 20 percent gets your full attention. If your team starts fighting the system to build ordinary screens, the system is wrong, not the team.
Review it once a year against the real product. Remove components nobody uses, promote patterns that appeared organically, and keep the whole thing small enough that a new designer can read it in an afternoon. A system that takes a week to learn will be worked around by the second week, and then you maintain two systems instead of one.
