Why Your Product Slowly Stops Looking Like One Product
One vendor built the company website, another developer built the internal dashboard, and a freelancer made the promo landing page. A year later your brand blue has four versions, the "Save" button comes in three sizes, and every new page starts with the same question: "which colour was it again?" Nobody did anything wrong on their own, yet the result looks like it came from different companies.
In our experience this isn't a taste problem. It's the lack of a single source of truth for visual decisions, and that's what a design system fixes. The good news: you don't need to copy Google or IBM. For a small team, a disciplined minimum beats a complete system that gets abandoned after three months.
What a Design System Is, and What You Actually Need
Nielsen Norman Group defines a design system as a complete set of standards for managing design at scale using reusable components and patterns. It usually has three layers: a style guide (colour, type, tone of voice), a component library (buttons, forms, cards), and a pattern library (combinations such as page headers or login forms).
The same article is honest about the cost: design systems take time to build and maintain, and for a prototype that will keep changing, a full system is unlikely to pay off soon. NN/g also describes three routes: adopt an existing system, adapt one, or create your own. The more custom, the more expensive.
For small teams we recommend the middle route: adapt components from a mature library, then lock in your brand at the lowest layer, the design tokens.
Layer 1: Design Tokens as the Foundation
The Design Tokens specification from the W3C Design Tokens Community Group, whose first stable version (2025.10) shipped in October 2025, describes tokens as a platform-agnostic way to express design decisions: at minimum a name and a value, such as color-text-primary: #000000. You define the value once, and both designers in Figma and developers in code use it.
The minimum token set we suggest:
- Colour: one brand colour, one accent, a grey scale, and status colours (success, warning, error).
- Type: one or two font families, a size scale (say 5–7 steps), and the weights you actually use.
- Spacing: one scale, such as multiples of 4 or 8 pixels. Ban numbers outside it.
- Radius and shadow: two or three levels each.
Use semantic tokens, not just raw ones
The spec supports aliases: one token can point to another. Use that to split tokens into two tiers:
- Raw tokens:
blue-600,gray-900. They hold values. - Semantic tokens:
color-action-primary,color-text-default. They hold intent and point to raw tokens.
Components only use semantic tokens. When the brand colour changes or you add dark mode, you change a reference instead of hunting colours across hundreds of files.
Fix: keep tokens in one file your code reads. If you're on Tailwind CSS v4, @theme variables already work as your token store: each one generates utility classes and a regular CSS variable. Elsewhere, plain CSS custom properties (--color-action-primary) are a fine start.
Layer 2: The Base Components You Really Use
Don't start with 60 components. Start with what appears on nearly every screen:
- Buttons (primary, secondary, destructive) with hover, focus, disabled, and loading states.
- Text input, select, checkbox, and the error message beneath them.
- Card or panel.
- Notification/alert.
- Modal or dialog.
- A simple table.
NN/g suggests each component gets a unique name, a usage description, adjustable attributes, its states, and a code snippet. For a small team, one documentation page per component is plenty, as long as the name in Figma matches the name in code exactly.
Best for: teams already using an off-the-shelf component library. Don't rewrite it; wrap it with your tokens and document only the variants you allow.
Layer 3: Accessibility Baked Into the Tokens
A design system is the cheapest place to get accessibility right, because you decide once and every page inherits it. The clearest reference is WCAG 2.2 success criterion 1.4.3 Contrast (Minimum): normal text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. The same page makes clear that brand guidelines don't exempt text from this rule; only logos are exempt.
Fix: test every text/background token pair before approving it, and record the result in your docs. Designers then never need to re-check contrast on each new screen. Give buttons and inputs a clearly visible focus style too, since keyboard users rely on it.
Mistakes We See Often
1. Starting with a perfect Figma file
Teams spend weeks on a beautiful design library that never connects to code. You end up with two sources of truth drifting apart.
Fix: start with tokens in code, then mirror the names in the design file. Code is what customers see.
2. Adding a variant for every request
"Can this button be a bit bigger?" Five requests later you're back where you started.
Fix: every new variant needs a written reason. If the reason is taste, use an existing variant.
3. No owner
NN/g stresses that a design system is only as good as the people who run it. On a small team that doesn't mean a dedicated team, but someone has to approve token and component changes.
Fix: name one owner and keep a simple changelog.
When You Don't Need One Yet
Honestly, not every business needs this now:
- You have one simple website that rarely changes. A one-page brand guide is enough.
- Your product is still a prototype and the design shifts weekly. Wait until patterns settle.
- You run on a fully managed theme in Shopify or WordPress. Set your tokens in the theme settings.
A design system starts paying off once you have two or more digital products, more than one person or vendor shipping UI, or a roadmap measured in years.
Minimum Design System Checklist
- Colour, type, spacing, radius, and shadow tokens live in one file your code reads.
- Components use semantic tokens, never raw values.
- Text/background pairs pass WCAG 2.2 contrast (4.5:1 for normal text).
- Six base components documented, states included.
- Component names match between design file and code.
- One owner and a changelog.
If you're planning a new website or app, put these needs into your project spec from day one. Still deciding whether to build or buy? See our build vs. buy framework.
The AY Labs Approach
We build design systems in the same order for every client: tokens first, base components second, just enough documentation. Tokens live directly in code, so design and implementation never fork into two versions. We check contrast on every colour pair before it ships, and we'd rather adapt a mature component library than build from scratch, unless your needs are genuinely unusual. The AY Labs site itself is built this way. If your digital products are starting to drift apart, we're happy to help lay the foundation.
