Glossary of scalable Design Systems

A reference for design system builders

This article is part of our complete guide to Design Systems. Start there for the big picture.

Design systems live at the intersection of design, engineering, and product strategy. The vocabulary can be disorienting, especially when the same term means different things at different companies. This glossary defines the concepts you’ll run into when building, maintaining, or contributing to a scalable design system.

A

Atomic design

Brad Frost’s methodology for structuring UI components into five hierarchical levels: atoms (basic HTML elements like buttons, inputs, and labels), molecules (simple combinations like a search field), organisms (complex sections like a page header), templates (page-level layouts), and pages (specific instances with real content). It gives you a mental model for building systems from small, composable pieces. See our Design System 101 guide for how to apply atomic design in practice.

B

Base token

A design token storing a raw, context-free value. Also called a primitive token or global token. Example: gray-700: #374151. Base tokens get referenced by semantic tokens but are rarely used directly in component code.

C

Component

A reusable, self-contained UI element with a defined structure, behavior, and visual appearance. Components are the building blocks — buttons, inputs, cards, modals, navigation elements. A well-built component hides its complexity behind a simple interface.

Composite component

A component made by combining smaller components. A form group (label + input + helper text + error message) is a classic example. Composites handle layout and coordination between their children while letting the underlying primitives handle rendering.

Contribution model

The process by which people outside the core design system team propose, design, build, and integrate new components or changes. A healthy contribution model includes submission templates, review criteria, and clear timelines. Without one, the system becomes a bottleneck.

D

Design token

A named, platform-agnostic variable encoding a design decision. Tokens replace hard-coded values (hex colors, pixel sizes, font names) with meaningful names that translate into CSS, iOS, Android, and any other platform. They’re the bridge between design intent and engineering implementation.

Documentation

The written and visual reference material explaining how to use the design system. It includes component specs, usage guidelines, code examples, design principles, and accessibility notes. A system without documentation is just a library of orphaned components.

F

Figma library

A shared Figma file containing all design system components as reusable assets. Teams subscribe to the library, and updates publish automatically across all consuming files. Think of it as the design-side equivalent of a code package registry.

G

Governance

The operational framework guiding how the design system evolves. It covers ownership, decision-making authority, review cadence, versioning strategy, deprecation policies, and conflict resolution. Good governance keeps things coherent without making them rigid.

Grid system

A spatial framework defining columns, gutters, and margins for page layout. Grids give you consistent alignment and proportion across screens. Common setups: 12-column grids for desktop, 4-column for mobile. Design tokens often encode grid values for cross-platform consistency.

H

Handoff

Transferring design specs to engineering for implementation. In mature design systems, handoff shrinks dramatically because components already exist in both design and code. The goal: reduce handoff to layout decisions and content, not individual component specs. Design-led development explores how to minimize handoff through continuous collaboration.

I

Icon system

A coordinated set of icons sharing consistent size, stroke weight, style, and metaphor conventions. Typically built on a standard grid (24x24 pixels is common) with naming conventions and usage guidelines. Icons usually ship as SVGs or an icon font.

L

Layout

The spatial arrangement of components on a screen — grid alignment, spacing between sections, responsive behavior, and content flow. Design systems define layout primitives like stack, grid, cluster, and sidebar to handle common arrangements.

M

Mode

A variation of a design token set applied across the whole system — most commonly light mode and dark mode. Modes swap semantic token values while keeping token names the same, so components adapt without code changes. Some systems also define modes for high contrast, brand themes, or density settings.

Multi-brand theming

Applying different brand identities to the same components by swapping token values. This matters for organizations running multiple products or brands from a shared component library. The component structure stays constant; only the tokens change.

N

Naming convention

Standardized rules for naming tokens, components, variants, and files. Consistent naming cuts confusion, enables automation, and makes the system searchable. Common patterns: kebab-case for tokens (color-action-primary) and PascalCase for components (PrimaryButton).

P

Pattern

A reusable solution to a common design problem involving multiple components working together. Patterns sit higher than components — a login flow, a data table with pagination, or a settings page layout are all patterns. They document how components combine to solve specific user needs.

Primitive

The most basic building block in a design system — either a primitive token (raw value) or a primitive component (basic element like a button or text input). Primitives get composed into increasingly complex structures.

S

Semantic token

A design token encoding meaning rather than a raw value. Example: color-text-primary maps to gray-900 in light mode and gray-100 in dark mode. Semantic tokens are what make theming, modes, and contextual adaptation possible.

Spacing scale

A predefined set of spacing values for padding, margin, and gap throughout the system. Usually based on a base unit (4px or 8px) following a geometric or linear progression: 4, 8, 12, 16, 24, 32, 48, 64. Consistent spacing creates visual rhythm and eliminates arbitrary decisions.

Storybook

An open-source tool for building, testing, and documenting UI components in isolation. It renders each component with its variants and states, works as living documentation, and enables visual regression testing. It’s the most widely adopted tool for design system dev environments.

T

Theme

A coordinated set of token values defining a distinct visual identity. A theme might represent a brand, a mode (light/dark), or a product variant. Themes apply globally and cascade through every component that references semantic tokens.

Token architecture

How design tokens are organized into layers: typically primitive, semantic, and component tiers. Token architecture determines how values flow from raw definitions to contextual meanings to component-specific applications. Get this right and theming, modes, and scaling become straightforward.

Typography scale

A defined set of font sizes, weights, line heights, and letter spacing values establishing typographic hierarchy. Usually five to eight levels, from small captions to large display headings, encoded as design tokens for cross-platform consistency.

V

Variant

A predefined variation of a component that serves a different context or use case while sharing the same core structure. A button might have variants for primary, secondary, tertiary, and destructive actions. Variants are designed and documented as part of the component spec, not created ad-hoc.

Version control

Tracking and managing changes to design system code and assets over time. Design systems use semantic versioning (major.minor.patch) to signal the nature of changes: major versions contain breaking changes, minor versions add features, patch versions fix bugs. This lets consumers upgrade on their own schedule.

---

This glossary covers the working vocabulary of design system work. I’ve tried to keep definitions grounded in how these terms are actually used on real teams, not how they appear in conference talks. For UX terminology beyond design systems, see our UX glossary A-Z. As the discipline matures, new terms will surface and existing definitions will tighten. Bookmark it and share it with teammates who are ramping up.