Every few months a small team decides it needs a design system, spends six weeks building component documentation nobody reads, and quietly goes back to copying the last page that looked right. The instinct is correct. The scope is usually wrong.

A design system is not a library. It is a set of decisions you agree to stop re-making. If you are a team of five, you probably need six of them.

Start with the decisions, not the components

Write down the answers to these, and you have covered most of what a marketing site needs:

• Type scale. Four or five sizes. Name them. Never invent a sixth in a hurry.
• Spacing rhythm. Pick a base unit and use multiples of it. Eight pixels is a fine default.
• Colour roles. Not “the blue” — the primary action colour, the surface colour, the border colour.
• Corner radius. Two values, maximum. Small for inputs, larger for cards.
• Elevation. Three shadows. Anything more and nobody can tell them apart anyway.
• Motion. One duration, one easing curve. Consistency reads as quality.

That is the whole system. It fits on a single page and it will survive four years of new hires.

Put the decisions where the work happens

A document nobody opens is a document that does not exist. In Divi, that means global colours and global fonts — change the value once and every module that references it updates. In code, it means CSS custom properties defined at the root.

The test of a design system is not how complete it is. It is whether the fastest way to do something is also the correct way.

Grow it only when it hurts

Add a component to the system the third time you build it. Not the first, when you do not yet know the shape of the problem. Not the second, when you might still be looking at a coincidence. The third time you have a pattern, and patterns are what systems are for.

Everything else — the token pipeline, the Storybook instance, the Figma library with variants for every state — is a solution to a problem you will know when you have it.