Design Systems

This deck walks through the foundational vocabulary of design systems, from high-level ideas like what a design system is and why it matters, down to specific building blocks such as design tokens, reusable components, patterns, and component APIs. You'll also find cards on the less visible but equally important parts of a system, including documentation, governance, contribution guidance, and a single source of truth. Together, they paint a picture of how teams keep their products visually and behaviorally consistent at scale.

It's a useful starting point whether you're a designer or front-end developer joining a team that has a design system, someone helping to build or maintain one, or a product person who wants to understand the language designers and engineers use every day. If you're preparing for interviews, onboarding into a new role, or just trying to get aligned with a cross-functional team, working through these cards can give you a shared vocabulary to draw on.

Because most of these concepts are definitions and ideas rather than facts to memorize in isolation, spaced review tends to work better than cramming. Try returning to the deck over several short sessions, and as you review, pause to connect each term to something you've actually seen in a product, codebase, or team you've worked with. That small habit of linking each concept to a real example will make the terminology stick far longer than rote repetition alone.

A design system is a shared set of principles, components, patterns, and rules that helps teams build consistent products faster. It exists because individual product teams repeatedly face the same design and engineering decisions, and a system provides reusable answers to those questions. The benefit compounds at scale: when many teams ship from the same toolkit, consistency improves, delivery speeds up, and redundant decision-making shrinks across the organization. A useful way to think about this is through the principle that a good design system makes the right choice the easiest choice. When using the system is faster than going around it, adoption follows naturally, and the system stops feeling like overhead.

Design systems are often confused with simpler artifacts. A style guide documents visual rules, such as colors, typography, and logos, but typically stops short of implementation. A component library is reusable UI code itself, but it lacks the surrounding principles, tokens, patterns, documentation, and governance that turn code into a system. The full design system layers all of these together: a brand made operational, an architecture that absorbs repeated decisions, and a shared vocabulary that lets designers, engineers, and product managers talk about UI with the same words. Visual consistency emerges from aligned spacing, typography, color, and interaction patterns; interaction consistency emerges from controls that behave predictably across the product.

A design system also operationalizes brand by translating abstract identity into concrete visual and interaction decisions in the product. When teams bypass the system, system debt accumulates: the inconsistency and duplication that emerge when shared patterns are fragmented. Strong systems are built for real product use rather than abstract theory, and they evolve as products, platforms, and user needs change. Continuous refinement based on real usage, not just catalog polish, is the durable habit that keeps a system alive.

A good design system rests on a small set of guiding principles that every team can repeat and apply. The most practical principle is to make the right choice the easiest choice: when system usage is frictionless, adoption follows without enforcement. Other principles like "real usage beats catalog breadth" or "designers and engineers co-own the system" keep the team honest when tradeoffs arise between visual polish and technical practicality. Co-ownership in particular helps ensure the system is both visually coherent and technically sound, because neither discipline can drive the system alone without producing artifacts that fail in the other's reality.

Governance is the process by which the system proposes, reviews, approves, and maintains changes. The three most common governance models differ in how authority is distributed. A centralized model puts a single team in charge, producing fast decisions but limited scale. A federated model lets distributed contributors propose changes while a core team reviews and merges, scaling further but requiring clear guardrails. The hub-and-spoke model balances both: a central core team plus embedded specialists in product teams who carry system thinking into real product work. Many large organizations also adopt an inner-source approach, treating the internal system like an open-source project with public issues, RFCs, and transparent decisions. The single source of truth is the authoritative place where current component definitions and guidance live, and forcing all decisions through one team creates bottlenecks; distributed authority with shared standards scales better.

Contribution guidance makes all of this work in practice. Clear rules for proposing, building, and merging changes keep the system from becoming a dumping ground or a bottleneck. Requests for Comments, or RFCs, are public proposals for significant changes that invite discussion before implementation, and structured design and code reviews critique contributions against system principles, accessibility, performance, and API consistency. Components move through explicit statuses: experimental (in active design or development with APIs that may change), beta (implemented in limited contexts but still fluid), stable (following semver with breaking changes reserved for major releases), and deprecated (scheduled for removal with active guidance toward a replacement). Versioning tracks change through a predictable cadence, often a release train with minor releases every two weeks and majors quarterly, so consumers can plan upgrades. Semantic versioning signals breaking changes through major version bumps, adds non-breaking features through minors, and fixes bugs through patches. Deprecation policies specify how long outdated components remain available before removal, with deprecation warnings in code or consoles giving consumers time to migrate, and codemods that automate the migration reduce upgrade pain dramatically. Office hours and dedicated chat channels provide high-leverage support, and the patterns of questions they surface often reveal what to improve next.

Design tokens are named values for color, spacing, typography, and other primitives that can be reused across tools and code. They are the atomic layer of a system: instead of writing a hex value in twenty places, the system exposes a token that resolves to that value everywhere. This abstraction is what makes consistency possible at scale, and it is also what enables theming, which means swapping values to produce alternative looks without changing component code. Tokens are usually organized into tiers. Tier 1 is the primitive layer of raw values with no semantic meaning, renamed only on major version bumps. Tier 2 is the semantic layer named for its role, such as color.text.primary or spacing.section, which is what most teams actually consume. Tier 3 is component-scoped, bound to a single component's needs. Alias tokens point to other tokens to share values while preserving semantic naming for swap-ability.

The single source of truth debate asks whether design tools or code should hold the canonical tokens, and the practical answer is increasingly a JSON file managed in Git and consumed by both sides. The W3C Design Tokens community specification defines a portable JSON format that lets tools exchange tokens, and Style Dictionary, an Amazon-built tool, transforms a single token source into platform-specific outputs for CSS, iOS, Android, and more. Tokens Studio brings this workflow into Figma, syncing tokens between design files and a code repository. Token transforms are pipeline steps that rewrite tokens for a specific platform, such as converting pixels to rems or color formats. The result is platform parity, where the same component behavior and look across web and mobile emerges from per-platform implementations aligned to one design source.

Theming is one of the most valuable capabilities that tokens unlock. Dark mode implementation defines dark-mode token values, ensures contrast ratios, and adjusts component behavior, for example, expressing elevation as a tint rather than a shadow. Multi-brand theming supports multiple brand identities through runtime or build-time token swaps. Context-aware theming adapts to user preference, system setting, or page area, such as an inverted hero section. Elevation tokens represent perceived layering, often encoded as shadow stacks or a tint plus blur amount. Shadow tokens are composite values of offset, blur, and color for a single elevation level. Z-index tokens name stacking levels like modal, dropdown, and toast so layering stays consistent without arbitrary integers scattered through code.

Visual rhythm comes from disciplined scales. A spacing scale is a geometric or linear progression of values used everywhere to enforce rhythm. A type scale is a modular progression of font sizes, often based on ratios like 1.25 or 1.333, that establish visual hierarchy. A fluid type scale uses CSS clamp to scale smoothly with the viewport, avoiding fixed breakpoints. A baseline grid aligns type to a common vertical rhythm that increases polish in dense layouts. The 8-point grid makes all spacing multiples of eight for easy mental math and alignment with most platform default densities, while a 4-point grid is common when finer increments are needed for icons or dense data UI. Density modes offer compact, comfortable, and spacious variants of components for different data densities, set through a token swap. Responsive component design uses container queries so components adapt internally to their container width rather than the viewport, enabling real component-level responsiveness as part of Jen Simmons' framing of intrinsic web design.

Atomic design, proposed by Brad Frost, gives teams a shared vocabulary for thinking about UI composition. Atoms are the smallest UI building blocks: a button, input, icon, or single token, not useful alone but combined into molecules. Molecules are small groups of atoms that work as a single unit, such as a labeled input with helper text and an error message. Organisms are complex UI sections composed of molecules and atoms, such as a navigation bar, card grid, or checkout form. Templates are page-level layouts that arrange organisms with placeholder content, and pages are templates populated with real content that users actually see. This bottom-up framing helps teams discuss UI at the right level of abstraction, while the pattern vocabulary above it captures higher-level solutions made of multiple components working together for common use cases.

Component API design is the practice of defining props, states, and variants so components are flexible without becoming confusing. A few habits separate good APIs from bad ones. Variants should be limited intentionally because too many make the system harder to learn, maintain, and use consistently. The prop count smell warns when a component has too many props, often more than ten: it is usually trying to be many components and should be refactored with composition. The boolean prop trap encourages replacing boolean toggles with a string enum so options remain readable and extensible. Conventions like a consistent named size scale, with tokens like xs, sm, md, lg, xl, reduce cognitive load across the system. An as prop supports polymorphism by allowing the rendered HTML element to change, for example, rendering a button as an anchor, while preserving styling.

Modern systems lean on composition over configuration. Compound components share context across subcomponents like Tabs.List and Tabs.Tab, producing a flexible and intuitive API. Slot patterns accept named children slots so consumers can compose flexibly without exposing every prop. Render props are a function-as-children pattern that lets consumers control rendering while inheriting behavior, powerful but less idiomatic in modern React. Headless components ship only behavior, including state, ARIA, and keyboard handling, with consumer-supplied markup; this is the pattern used by Radix UI, Headless UI, and Reach UI. shadcn/ui extends this with copy-paste recipes built on Radix and Tailwind, designed explicitly for deep customization rather than as a traditional library. Styling choices also matter: utility-first frameworks like Tailwind CSS compose design via class names, CSS-in-JS solutions like Emotion and styled-components provide flexibility at runtime cost, CSS Modules offer locally scoped CSS as a middle ground, and zero-runtime tools like Vanilla Extract provide type-safe styling compiled at build time. Open Props offers a collection of CSS custom properties forming an open-source design token set. Modern systems often blend approaches rather than pick one, and the utility-first debate increasingly resolves into a question of which blend fits the team's workflow. System components serve many products, while product components serve one and are usually built on top of system primitives.

Accessibility should be built into a design system from the start so that every team inherits better behavior instead of fixing the same issues repeatedly. The shorthand a11y refers to the eleven characters between the first "a" and the "y" in the word. The international standard is the Web Content Accessibility Guidelines, or WCAG, organized around four principles often remembered as POUR: Perceivable, Operable, Understandable, and Robust. Every guideline maps to one of these principles. Conformance levels are A for must, AA for should, and AAA for advanced, and most public systems target AA. Accessible defaults let every team inherit better behavior without having to remember or implement the rules in every product.

A few rules cover most practical accessibility work. Color contrast is foundational: WCAG AA requires a 4.5:1 luminance ratio between text and background for normal text, 3:1 for large text, and 3:1 for non-text UI components like icons, focus indicators, and form borders. Color alone should never convey state, since a red dot without an icon, label, or pattern fails color-blind users. Keyboard accessibility demands that every interactive element is reachable and operable via keyboard alone, with a logical tab order that matches the visual reading order; out-of-order tabbing disorients keyboard and screen reader users. Focus must be visible at all times, and modals typically need a focus trap so keyboard users do not tab into hidden background content. A skip-navigation link helps keyboard users bypass header navigation on long pages.

ARIA, the Accessible Rich Internet Applications specification, supplements native HTML semantics when they fall short. The first rule of ARIA is to prefer native HTML elements whenever possible, since native semantics are more reliably supported than custom ARIA constructions. When ARIA is necessary, aria-label provides an accessible name when visible text is unavailable, aria-labelledby points to existing text that should serve as the name and is preferred when visible text exists, and aria-describedby points to supplementary text like helper copy on a form input. aria-live marks dynamic regions so screen readers announce updates politely or assertively. Screen readers like NVDA, JAWS, and VoiceOver convert UI to speech or braille. Touch target sizes follow WCAG's 24x24 CSS pixel minimum, with mobile platforms recommending 44 to 48 pixels to reduce mis-taps. Motion should respect the prefers-reduced-motion user preference, disabling or simplifying animations for users who need them. Automated accessibility tests built on tools like axe-core catch a portion of WCAG violations, but manual review remains required. Periodic accessibility audits confirm the system continues to meet standards as it evolves.

Documentation is the surface through which consumers actually experience the system. Component documentation explains when to use a component, how it behaves, and what variants or constraints apply. Examples are essential because they show teams how to apply abstract guidance correctly in real interfaces, and anti-patterns, which document what not to do with the reasoning behind each, prevent shortcuts that create UX or maintenance problems. Many systems also include content guidance because words shape usability: components often need explicit labels, helper text, and error-state copy to be usable in practice. Icon libraries are not just collections either: they come with usage guidance on pairing labels, sizing, and when to use which icon, and discoverability is solved by strong naming, search, and search-first documentation that surfaces the consumer's actual words, including misspellings and synonyms, with redirect-from-aliases mapping common alternative names to canonical pages.

The documentation site is the canonical landing place, often built with Storybook, Docusaurus, or ZeroHeight. Storybook is a workshop tool that builds UI components in isolation and documents their variants, states, and controls; its play function enables scripted interactions inside a story, supporting visual testing of behavior. Chromatic captures pixel diffs for visual regression testing against known-good baselines. Platforms like ZeroHeight, Backlight, and Knapsack host components, tokens, docs, and previews together, often bridging Figma and code references. Storybook composition combines multiple Storybook projects into one site so consumers see the core system alongside their own product extensions. Changelogs record every change shipped, organized by version, and migration guides walk consumers through breaking changes, complementing codemods with narrative explanation.

Closing the parity gap between Figma and code is one of the most important ongoing tasks. The parity gap is the difference between what Figma and code can produce; design-to-code parity ensures component variants, states, and tokens match exactly between the Figma library and the code library. Figma Variables are Figma's native token primitive, with swappable modes per file, page, or frame implementing theming inside Figma, organized into collections with shared modes, and scoped to restrict which properties a variable can bind to so they cannot be misused. Tokens Studio syncs tokens between Figma and Git, allowing both sides to evolve together. The Plugin API exposed by Figma and Sketch lets teams build custom tooling: checks, sync scripts, codegen, and design linting that catches drift early by checking designs against conventions for color usage, spacing, and naming. Some components are production-only because they exist in code without a Figma representation, for example, infrastructure wrappers, while design-only components should be labeled "experimental" so they are not adopted prematurely. Code-first approaches build components in code first and reflect them in Figma, favored when engineering velocity dominates, while design-first approaches design in Figma first and implement in code, favored when design exploration dominates. Code Connect is a Figma feature that maps Figma components to code snippets, closing the design-code gap directly. Tests verify quality across layers: visual regression tests catch unintended UI changes, snapshot tests catch structural ones, interaction tests verify behavior, and accessibility tests catch a portion of WCAG violations automatically.

System adoption is the degree to which product teams actually use the design system in day-to-day work, and it is the most honest measure of value. Adoption often fails when the system is hard to use, poorly documented, or disconnected from product reality, when using it is slower or more painful than going around it. A component inventory, a review of existing UI to identify duplication, inconsistency, and standardization opportunities, is a practical starting point for diagnosis and roadmap planning. Useful metrics include the adoption rate, which is the percentage of UI built with system components versus ad-hoc UI, the coverage metric showing the percentage of product needs the system can serve out of the box, defect reduction, and speed of delivery. Outcome-based design system OKRs like adoption rate, accessibility coverage, and contribution volume move the team beyond simply shipping components.

Drift happens when product UI diverges from the system over time, and it is usually a signal that the system itself is insufficient for real needs. Public roadmaps set expectations and invite coordination across product teams, and surfacing success stories, real examples of teams shipping faster or better with the system, drives adoption and funding by making the value visible. Showcases of system components in real product UI prove that the system works at scale. The design-system maturity model traces a typical arc: Stage 0 is ad-hoc work where every team builds its own UI from scratch; Stage 1 is a static style guide with colors, type, and basic guidance not built into code; Stage 2 is a coded component library with basic reusable components but without strong documentation or governance; Stage 3 is a full design system with tokens, components, patterns, accessibility, governance, and contribution model; Stage 4 is a multi-platform, multi-brand, multi-product system with sophisticated tooling and a sustainable team. Mature systems are exemplified in the industry by Adobe's Spectrum, Google's Material Design, IBM's Carbon, Shopify's Polaris, Salesforce's Lightning, Microsoft's Fluent, GitHub's Primer, and Atlassian's design system, while the Design Systems Coalition is a cross-company community where practitioners share patterns, tools, and best practices.

At every stage, the bus factor, meaning how many people would have to leave before the system collapses, should be greater than one. Naming conventions and a documented component status prevent the no-name component problem that breeds duplication, and the API stability test asks of any new component, "What changes would force a major version bump?", a useful way to keep APIs honest. A periodic content audit reviews documentation freshness because outdated docs lose trust quickly. Above all, the most important factor in design system success is real usage in real products: a smaller, well-used system beats a larger, ignored one every time. The principle closes the loop: when the right choice is the easy choice, adoption follows.