The Design System: infrastructure, not decoration.

The phrase design system has become so overloaded that it's worth saying clearly what one actually is. It is not a Figma file with components. It is not a Storybook. It is not a colour palette and a typography page. Those are parts of a design system. A design system is the agreement between design and engineering, encoded in code and in documentation, about how the surface of your product looks, behaves, and is built. It is infrastructure. When it works, nobody notices it. When it doesn't exist, every team you have rebuilds the same button six different ways, and the cumulative cost of that, measured in re-work, accessibility regressions, brand drift and onboarding time, is enormous.

The mistake most organisations make is to treat the design system as a project. We'll do the design system in Q3. Design systems aren't projects. They're products with their own backlog, their own users (your engineers and designers), their own roadmap. They start small, they earn their keep, and they grow with adoption. A team that treats it as a one-off deliverable produces an artefact that's out of date the moment it ships.

The four layers, bottom-up.

A design system has four layers. They build on each other. You cannot skip a layer, though many teams try, without paying for it later.

• Tokens. The atomic values. Colour, spacing, typography scale, radii, shadow, motion duration. Held as variables, in code and in your design tool, and referenced by name, never by value. Brand-primary, not #E8B521.
• Components. The reusable UI elements. Button, input, card, modal, table, tabs. Built from tokens. Each one shipped in code with documented props, accessible by default, with variant states (default, hover, focus, disabled, error, loading).
• Patterns. The compositions of components into common solutions. A form (label + input + help text + error). A dialog (modal + close + actions). A toast. A page header. Patterns answer how do we usually solve this problem?
• Guidelines. The written rules — voice, content, accessibility, when to use which pattern. The bit that lives on the docs site. Last to build, first to skip.

When you actually need one.

Not every team needs a design system. A two-person product team building a single web app does not. The cost of building and maintaining the system exceeds the cost of just being disciplined in the codebase. The signal that a system has become necessary is roughly: three or more products sharing brand, five or more designers producing work, or ten or more engineers touching the UI. Below those thresholds, you can usually get by with shared variables and a strict review culture. Above them, you can't.

The other signal is brand inconsistency that you can see. Open three screens from three products in your suite, side by side. Are the button radii the same? Are the input heights the same? Does the primary action have the same colour, the same weight? If the answer is no, you have a system problem dressed up as a discipline problem. No amount of design review will fix it. The fix is shared infrastructure.

The "we should build a design system" trap.

The opposite failure is premature. A team of four building their first product decides they need a design system. They spend two months in Figma, draw fifty components, document them in a Notion page nobody reads. The product still ships with seventeen button variants, because the system was built in isolation from the work it was meant to serve. The team that built it leaves. The next team doesn't touch it because it doesn't match their reality.

The right time to extract a component into the system is when you have used it in three places. The right time to start the system is when the first painful inconsistency appears across products — not before. Build the system from the products, not for them. That's the inversion most teams get wrong.

What an MVP design system looks like.

An MVP design system is small enough to land in two sprints and useful enough to prove its worth. Roughly:

• Tokens. Colour scale (10-12 values), spacing scale (8-point increments), typography scale (5-6 sizes), radii (3 values), shadows (2-3 values). Held as code variables and as Figma variables, kept in sync.
• Ten components. Button, input, select, checkbox, radio, card, modal, toast, navigation, table. Each with full state coverage. Each accessible. Each documented in Storybook.
• No docs site yet. A README in the repository and a single Figma library page. The docs site is the layer most teams build first and use least. Skip it until you have ten adopters asking for it.
• One owner. The system has a named maintainer. Without one, drift starts on day fourteen.

That is enough to start. From there, the system grows by request — engineering asks for a component, the maintainer scopes it, the team builds it together. Tight loop. No grand vision document.

Naming, versioning, governance.

The three things that kill design systems quietly, in this order. Naming first: if your tokens are called blue-500 and you rebrand, every reference breaks. Name by semantic role, not by appearance (brand-primary, surface-default, text-emphasis), so the value can change without the name changing. Versioning second: ship the system as a versioned package. Breaking changes get a major bump. Consumers opt in. Governance third: write down who can add components, what the bar is, and what the deprecation policy looks like. Without that, every team adds their own divergent component and you've built a buffet, not a system.

The systems worth reading.

If you want to see what good looks like at scale, four are worth studying. Google's Material is the most thorough; it's also overcooked for most teams and worth borrowing structurally, not literally. Atlassian Design System is excellent on token architecture and on the documentation side. Shopify Polaris is the cleanest example of content guidelines woven into the system. IBM's Carbon is the most rigorous on accessibility and on multi-brand theming. None of them are templates. They are evidence that the discipline pays off.

Where this lands at Product Pieces.

When we run with a team that has the three-products-or-more shape, an MVP design system is usually part of the Foundations Set Piece — though we'll only build it if the products are diverging in ways the team can see. The output is the ten components, the token set, the ownership, and a backlog of the next ten components in priority order. We don't build the docs site. The team builds that themselves, once they want it.

If your organisation has the symptom (buttons rebuilt in every repo, brand drift between products, designers re-drawing the same modal), the missing piece is rarely more talent. It's shared infrastructure, named and owned.

Next issue: N°14 — Accessibility. The floor, not the ceiling.