Design System Basics: A Practical Guide

Design systems get either too much hype or too little discipline. Done well, they speed every product decision and protect quality at scale. Done badly, they become bureaucratic theater. This guide covers what's actually in a design system and how to build one without losing the team in the process.

The Layers

LayerContentsPurpose
TokensColor, type, spacing, radius, shadow valuesAtomic, semantic values; theming foundation
ComponentsButtons, inputs, modals, cards, navReusable building blocks with defined behaviour
PatternsForms, empty states, navigation, data tablesHow components combine for common UX flows
TemplatesPage layouts, dashboard structuresHigher-level scaffolds
DocumentationUsage rules, props, examples, accessibilityEnables adoption without 1:1 support
GovernanceContribution process, review, versioningKeeps the system trustworthy as it grows

Tokens First

The foundation of every design system is a token layer — named values that everything else references. Common starter set:

  • Color: primitive scales (gray-100 to gray-900, brand-50 to brand-900) and semantic aliases (--bg-surface, --text-primary, --border-default).
  • Type: a scale (xs, sm, base, lg, xl, 2xl...) plus line-height and weight tokens.
  • Spacing: a step scale (4, 8, 12, 16, 24, 32, 48, 64) used for padding, margin, gap.
  • Radius: typically 4-6 values (none, sm, md, lg, full).
  • Shadow: 3-5 elevation steps.
  • Motion: durations and easing curves.

Component Patterns That Work

  • Define variants explicitly — primary, secondary, ghost, danger — not ad hoc styling.
  • Standardise sizes — sm, md, lg — consistent across the component set.
  • Specify states — default, hover, focus, active, disabled, loading — every component, every variant.
  • Accessibility is non-optional — focus rings, ARIA, keyboard, contrast must all be solved at the component level.
  • Document props and examples in code — Storybook or equivalent. A Figma file alone is insufficient.

Avoid Common Mistakes

  • Launching the system before consumers adopt it. Build with one team's real needs, then expand.
  • Token names that encode the value (--color-blue-500). Encode meaning (--color-brand-500).
  • No governance — anyone can add components, no one removes anything. The library balloons and trust collapses.
  • Skipping documentation. Undocumented systems are abandoned systems.

Try It Yourself

Build a token palette with DesignKit's color and gradient tools.

Color Palette Extractor →

Frequently Asked Questions

A structured, reusable set of design decisions packaged with docs and code so teams build consistent products.
Atomic named values (colors, sizes, spacings) that everything references. Foundation for theming and consistency.
When multiple people make decisions or consistency is breaking down. Single-person teams usually don't need one.
Both. Design source of truth + code source of truth, kept in sync via tokens.
Tokens + 5-10 core components + documentation. Expand only as adoption proves the value.