UtilityMay 8, 2026 · Updated Oct 14, 2026 · 4 min read

How to Create a Design System from Scratch (2026)

How to build a design system that tools and people can both use: tokens in the W3C community group's first stable format (October 2025), generated color and spacing scales, components built only from tokens, and a 2026 experiment where a design-system-aware workflow cut delivery time by up to 69%.

🎨

Try the Brand Kit Generator

Free, no signup

→

DG

Derek Giordano

Designer & Developer

What a Design System Is

A design system is the shared set of decisions behind an interface: tokens (named values for color, type, spacing, radius and motion), components built only from those tokens, and documentation that says when to use what. Its job is consistency at speed: a new screen should be assembled from parts that already agree with each other.

There is now controlled evidence on the speed part. Silva and colleagues (2026, found through alphaXiv) ran an experiment at a large Brazilian company across Angular, iOS and Android, comparing manual development, development with the design system only, and AI-assisted development that worked from the design system. The AI-assisted condition cut time to delivery by 46.7% to 69.4%, with more complete tasks and less variation between developers. The common thread is that the system has to be machine-readable for tools to use it, which starts with the tokens.

Tokens in a Standard Format

Tokens used to live in each tool's own format. The W3C Design Tokens Community Group published the first stable version of its JSON format, Design Tokens Format Module 2025.10, on October 28, 2025, so one token file can now feed design tools, code generators and documentation. A token is a name, a $type and a $value; colors are objects with a color space, components and an optional hex fallback, dimensions carry a value and a unit, and tokens can reference each other:

{
  "color": {
    "blue-600": { "$type": "color",
                  "$value": { "colorSpace": "srgb", "components": [0.145, 0.388, 0.922], "hex": "#2563eb" } },
    "action":   { "$type": "color", "$value": "{color.blue-600}" }
  },
  "space": {
    "3": { "$type": "dimension", "$value": { "value": 0.75, "unit": "rem" } }
  }
}

Name semantic tokens by role (color.action, color.danger) on top of raw palette tokens, so a rebrand changes one reference instead of every component. Our Design Token Generator exports this format, and we checked its output by compiling it with Sass, Tailwind's CLI and Terrazzo.

Color and Spacing Scales

Generate scales rather than picking values by eye. The Design System Builder makes 10-step color scales in OKLCH, which keeps steps evenly spaced in perceived lightness, and spacing scales you can export to Tailwind. When we tested its Tailwind export, spacing keys had been overriding Tailwind's own units (p-4 came out as 6 px on one scale); they now map so that p-4 stays 1rem and new steps get their own keys. Check contrast as you go: our accessible palette guide lists which Tailwind steps pass for text.

Components From Tokens Only

A button should reference var(--color-action) and var(--space-3), never a hex code or a pixel value. Start with the components every screen uses, such as button, input, select, checkbox, card, modal and alert, and give each its states (hover, focus, disabled, error) before adding new components. A component that needs a value the tokens do not have is a signal to add a token, not to hard-code one.

Documentation and Adoption

• Show each component with its variants and states, a code example, and do and don't examples.
• Record decisions with the reason, so the next person does not undo them.
• Version the system and announce breaking changes; a token rename is a breaking change.
• Measure adoption by how much of the product uses the components, not by how many components exist.