Design systems guide — building scalable visual languages

Understanding design systems is the foundation of this guide. Below we break it down step by step so you can act with confidence.

A design system is a collection of reusable components, guided by clear standards and documentation, that can be assembled to build any number of applications. It is the single most important investment a product design team can make — it eliminates redundant work, enforces consistency and accelerates every future design and development project.

This lesson covers how to build a design system from scratch — from design tokens and components to governance, documentation and adoption.

Design systems foundations: tokens and primitives

Design tokens are the atomic values — colors, spacing, typography, shadows, border radii — that form the foundation of every component in the system.

• Color tokens — define semantic colors (primary, secondary, surface, text, error, success) rather than literal colors (blue-500). Semantic naming allows theme switching (light/dark) without renaming variables.
• Spacing scale — a fixed set of spacing values: 4, 8, 12, 16, 24, 32, 48, 64, 96px. Every margin, padding and gap uses a value from this scale. Consistent spacing is what makes designs feel 'designed' versus thrown together.
• Typography tokens — font family, weight, size, line height and letter spacing for each level: display, heading (H1–H6), body, caption, overline. Combine into named styles (text-heading-lg, text-body-md).
• Elevation tokens — shadow values for different levels: card (subtle), dropdown (medium), modal (heavy). Consistent elevation creates clear spatial hierarchy.
• Border radius tokens — small (4px), medium (8px), large (16px), pill (999px). Every rounded corner uses one of these values.

Tokens should be implemented in both Figma (as variables) and code (as CSS custom properties or a tokens JSON file). Keeping both in sync is the first challenge of design system maintenance.

Building components for a design system

Components are the reusable UI building blocks assembled from tokens. Build them from atomic to complex.

• Atoms — buttons, inputs, labels, icons, avatars, badges. The smallest functional units.
• Molecules — search bars (input + button), form fields (label + input + helper text), card headers (avatar + name + timestamp).
• Organisms — navigation bars, cards, forms, tables, modals, sidebars. Composed of molecules and atoms.
• Templates — page-level layouts that define where organisms sit: dashboard layout, settings page, onboarding flow.

Each component needs: a Figma component with variants (states, sizes, themes), coded equivalent (React/Vue/Web Component), documentation (when to use, when not to, props/variants, accessibility notes) and tests.

• Variant coverage — every component needs at minimum: default, hover, focus, active, disabled states. Interactive components also need: loading, error, success states.
• Responsive behavior — document how each component adapts: does it stack, shrink, hide or truncate on smaller screens?
• Accessibility — every component must meet WCAG AA: proper contrast ratios, keyboard navigation, ARIA labels, focus indicators.

Design systems governance and documentation

A design system without governance degrades into a collection of outdated components. Without documentation, nobody uses it.

• Contribution process — define how new components are proposed, reviewed, built, tested and published. A clear process prevents fragmentation.
• Versioning — use semantic versioning (major.minor.patch). Breaking changes increment major, new components increment minor, bug fixes increment patch.
• Documentation site — every component has a page with: visual examples, usage guidelines (do/don't), code snippets, prop documentation, accessibility notes and related components.
• Adoption metrics — track what percentage of product screens use system components versus custom one-offs. The metric reveals whether the system is actually being used or ignored.
• Deprecation — when a component is replaced, mark it deprecated with a migration guide. Give teams a timeline (e.g., 2 sprints) to migrate before removal.

The design system is a product, not a project. It needs a dedicated owner (or team), a roadmap, a backlog and regular releases — just like any other product.

When evaluating design systems, start with the fundamentals: what problem it solves, who it serves, and how it compares to the alternatives buyers consider first.

Start with the fundamentals. Define who you are serving, the single outcome you want, and the budget you are comfortable committing before you compare any options.

A practical rule is to favour clarity over cleverness. The choice that is easiest to understand, spell, remember and act on tends to win over the long run.

Context changes the answer. What is optimal for a fast-moving startup is rarely optimal for an established brand, so weigh your own stage, market and ambitions.

Avoid the common mistakes: rushing the decision, copying competitors blindly, and ignoring the total cost of ownership beyond the very first year of use.

Think in terms of trade-offs rather than a single perfect answer. Every option trades memorability, cost, reach and flexibility in a slightly different mix.

Document your reasoning. Writing down why you chose one path makes it far easier to revisit the decision later and to explain it to partners and investors.

Test with real people. A quick check with a handful of your actual customers will surface problems that no amount of internal debate ever reveals.

Plan for growth. The option that fits today should still make sense when your audience, catalogue or team is several times larger than it is right now.

Finally, revisit the decision periodically. Markets, tools and best practices move quickly, and a choice that was ideal last year may deserve a fresh look today.

When evaluating design systems, start with the fundamentals: what problem it solves, who it serves, and how it compares to the alternatives buyers consider first.

Start with the fundamentals. Define who you are serving, the single outcome you want, and the budget you are comfortable committing before you compare any options.

A practical rule is to favour clarity over cleverness. The choice that is easiest to understand, spell, remember and act on tends to win over the long run.

Context changes the answer. What is optimal for a fast-moving startup is rarely optimal for an established brand, so weigh your own stage, market and ambitions.

Avoid the common mistakes: rushing the decision, copying competitors blindly, and ignoring the total cost of ownership beyond the very first year of use.

Frequently asked questions

When should a team start building a design system?

When the same component is built differently in 3 or more places. Before that, you are solving a problem that does not yet exist. Start with the components you already have — audit, consolidate and document existing patterns before creating new ones.

Should the design system be built in Figma or code first?

Build in parallel. A Figma-only system helps designers but not developers; a code-only system helps developers but not designers. The real value comes from keeping both in sync with a shared set of design tokens as the single source of truth.