Design systems glossary

A design system is a coordinated collection of reusable components, design tokens, and documented rules that lets multiple teams ship a coherent product without re-deciding the same questions. The system is the artifact; the practice around it is what makes it useful.

A design token is a key/value pair that captures one design decision — a color, a spacing step, a font size, a duration — in a form that can be consumed by code, Figma, and any pipeline in between. Tokens are the smallest unit of a design system. Without tokens, the same color is decided in eighty places; with them, it's decided once.

Related: Primitive token · Semantic token · Component token

Primitive (sometimes 'reference' or 'global') tokens hold raw values: `blue-500: #2563eb`, `space-4: 16px`. They have no usage opinion attached. Other tokens reference them. Primitive tokens are stable across themes and re-skins.

Semantic tokens carry intent: `color-text-default`, `color-bg-critical`, `space-stack-md`. They reference primitive tokens and are what components consume. Semantic tokens are what allow a single component to flip from light to dark mode, or from one brand theme to another.

Component tokens further specialize semantic tokens for a specific component: `button-primary-bg`, `card-padding`. They give component authors targeted override points without breaking the broader system. Use sparingly — most needs are met by semantic tokens.

The W3C Design Tokens Community Group format defines tokens with `$value`, `$type`, `$description`, and reference syntax (`{color.primary}`). Tokens Studio for Figma, Style Dictionary, and a growing number of tools support this format natively. Adopting it makes your tokens portable across the entire ecosystem.

Brad Frost's atomic design model groups components into atoms (raw elements), molecules (simple groupings), organisms (complex sections), templates (page-level layouts), and pages. The model is useful as a vocabulary; less useful as a strict folder structure. Most working design systems borrow the language without enforcing the hierarchy.

In a centralized model, a single design system team builds and maintains every component, token, and pattern. Product teams consume but don't contribute directly. Pros: tight quality bar, consistent voice. Cons: bottleneck risk; the central team becomes a service desk.

In a federated model, the design system is governed by a small core but contributed to by every product team. Components must meet shared criteria (a11y, theming, API conventions) but they're built across the org. Pros: scales without growing the core team. Cons: requires real governance discipline or it drifts.

Hybrid governance keeps tokens, primitives, and the most foundational components owned by a central team — and lets product teams contribute downstream patterns under a contribution model. Most large design systems converge on this model after a few years.

DesignOps is the discipline of running design as a function: hiring, tooling, rituals, metrics, asset management, and the boring infrastructure that lets designers and engineers ship without re-inventing process. Design systems are one DesignOps lever among many.

A component's contract is its API surface (props), its visual states, its accessibility behavior, and its theming hooks. Breaking the contract breaks consumers; preserving it lets the component evolve internally without ripple effects. Think of it as a versioned interface, even when not enforced by tooling.

Visual regression testing renders a component (or page) and diffs the output against a baseline screenshot. Anything that changes pixels — intentional or not — surfaces as a failure for review. Tools: Chromatic, Percy, Playwright with screenshot assertions, BackstopJS. Essential for any design system at scale.

Accessibility (abbreviated 'a11y' for the eleven letters between a and y) is the practice of building products that work for users with disabilities — visual, motor, cognitive, or auditory. WCAG defines the standards. In a design system, accessibility belongs at the component level: a button is built once, and every team gets correct focus, ARIA, and contrast for free.

WCAG is the W3C's standard for accessible web content, organized around four principles: perceivable, operable, understandable, robust. AA conformance is the de facto baseline; AAA is aspirational. WCAG 2.2 (2023) is the current published version; WCAG 3 is in draft.

ARIA is a set of HTML attributes (roles, states, and properties) that describe non-native UI patterns to assistive technology. Used correctly, ARIA fills gaps in native HTML semantics; used incorrectly, it actively breaks accessibility. The first rule of ARIA is: don't use ARIA when native HTML will do.

A theme is a complete token set — light or dark, brand-A or brand-B, default or high-contrast. Components stay the same; the theme swap changes which token values resolve. Good design systems isolate themeable values into semantic tokens so themes can swap without touching components.

Dark mode is a theme that inverts the surface/text relationship: dark backgrounds, light text. Implementing it well requires semantic tokens (so components don't reference raw colors), care with shadows and image content, and respect for the user's OS preference via `prefers-color-scheme`.

A slot is a named insertion point in a component where consumers pass arbitrary content. React's children are an unnamed slot; Radix's `<Slot />` and Vue's named slots formalize the pattern. Slots are the alternative to prop explosion: instead of fifteen optional props, expose three slots.

Compound components let consumers compose: `<Tabs><Tabs.List><Tabs.Trigger>...</Tabs.Trigger></Tabs.List></Tabs>`. The parent manages shared state via context; the children are dumb building blocks. The pattern trades verbosity for flexibility — the parent can support any layout, not just the one a single `<Tabs items={[...]} />` API would force.

Headless components ship logic, state, and accessibility behavior, leaving styling entirely to the consumer. Radix UI, React Aria, and Headless UI are the canonical examples. Headless is what most modern design systems build on top of: behavior is the hard part, styling is the easy part.

Storybook is the de facto component playground — a sandboxed environment for rendering components in isolation, with controls for props, accessibility checks, and visual testing. For most design systems, Storybook is the documentation site for engineers, complementing the marketing/prose site for designers.

Tokens Studio (formerly Figma Tokens) is the most-used Figma plugin for authoring and managing design tokens. It supports the W3C tokens format, exports to JSON, and integrates with Style Dictionary and code repositories. The de facto bridge between Figma and code in 2026.

Style Dictionary takes a token source (JSON) and transforms it into platform-specific outputs: CSS variables, Sass, Tailwind config, Android XML, iOS Swift, and more. The reference build tool for any design system that needs tokens to flow into multiple platforms.

Libraries are how Figma propagates components and styles from a source file to consuming files. Updates publish from the library; consumers pull updates explicitly. Libraries are the design-side analog of an npm package: versioned, shared, and meant to be consumed at scale.

Code Connect lets you point a Figma component at its corresponding code component and prop API. When designers inspect the component in dev mode, they see the actual code import path and prop names — not a guessed CSS dump. Critical infrastructure for any team using Figma's MCP server with AI coding agents.

MCP (Model Context Protocol) is Anthropic's open standard for exposing tools, resources, and prompts to AI coding agents (Claude Code, Cursor, Codex). A design system's MCP server can expose tokens, components, and documentation directly into an agent's context, making the agent design-system-aware without prompt-stuffing.

Variants are the named options a component supports along a given axis: a button has `intent` (primary, secondary, destructive), `size` (sm, md, lg), `state` (default, loading, disabled). Good design systems keep the variant matrix small and documented; bloated variant matrices are a sign the component should be split.

Density is the rhythm of spacing inside a UI: compact (data-dense, less padding), comfortable (default), spacious (more breathing room). Few public design systems support density modes explicitly — Salesforce SLDS is one of the exceptions. Density matters most for data-heavy enterprise UIs.

The accessibility tree is the structured representation of a UI that screen readers and other assistive technology consume — derived from the DOM but not identical to it. Good a11y means designing the accessibility tree, not just the DOM. Tools like the browser's Accessibility Inspector show what the AT actually sees.

When a modal opens, focus should land on a meaningful element inside it; when it closes, focus should return to the element that opened it. Trap focus inside the modal while it's open. These behaviors are tedious to write from scratch, which is why headless libraries (Radix, React Aria) ship them as primitives.

Geometric centering ('center the icon by its bounding box') often looks wrong to the eye because asymmetric shapes have visual weight that doesn't match their geometry. A play-button glyph centered geometrically looks left-shifted; nudging it 1–2px right makes it look correct. Optical alignment is design's craft layer over math.

IA is the structure and labeling of information across a product or site — the hierarchy, the navigation, the categories. Good IA is invisible; bad IA forces users to learn an arbitrary mental model. For a design system site, IA is what determines whether a foundations page is discoverable.

Empty states are what a screen looks like before the user has any data — first launch, after a search returns nothing, when a list is cleared. Good empty states explain what the screen will become and offer one obvious next action. Most design systems underdocument empty states; the strong ones (Polaris, Atlassian) show the difference.

Loading states keep the user oriented while data arrives: skeletons that match the eventual layout, progress bars when duration is known, spinners only as a last resort. Generic centered spinners are a code smell — they hide what's coming and feel longer than they are.

Error states tell the user something didn't work, why (when honest), and what they can do next. The two failure modes are 'Oops!' (cute and useless) and silent retries (mysterious). Both are worse than 'Connection lost. Tap to retry.'

Voice is the consistent personality of a product across all writing; tone is how that voice shifts by context (calm in errors, celebratory in onboarding, neutral in settings). Public references: Mailchimp, GOV.UK, Polaris. Voice and tone is design system content the same way buttons and tokens are design system code.

Naming conventions are how a design system encodes structure into strings: `color-bg-default`, `space-stack-md`, `Button.Primary`. Good conventions are predictable, machine-parseable, and survive expansion. Bad conventions (`@orange-medium-2`) lock in implementation detail or visual specifics.

Maturity models describe the stages a design system passes through — from ad-hoc styles, to a shared library, to a fully governed system with metrics and adoption tracking. Useful as a diagnostic, not as a forced linear path; many systems sit in different stages on different axes (great tokens, weak governance).

Quantifying design system ROI looks at design speed, dev speed, defect rate, time-to-onboard, and consistency — usually compared against a no-system baseline. The fastest credible numbers come from before/after measurement on a small slice; whole-org ROI claims are usually estimates.