A design system is not a Figma file with a component library. That is the most common misunderstanding in product teams - and it is why so many "design systems" break down six months after they are introduced. A real design system is a living infrastructure layer: the single source of truth that connects design decisions to production code, maintained by a governance process that keeps both sides in sync.

Ravve Jay Prevendido of TTGC Global builds design systems for clients across SaaS, fintech, healthcare software, and digital products. The anatomy is always the same: design tokens at the foundation, a component library on top of those tokens, documentation that makes it usable without training, and a governance model that keeps it from going stale.

Understanding this architecture changes how you evaluate whether what your team has is actually a design system - or an expensive collection of components that will diverge from production within a quarter. If you want to understand the broader context, the comparison between custom software vs off-the-shelf approaches applies equally to design infrastructure.

Layer 1: Design Tokens - The Atomic Foundation

Design tokens are the lowest-level decisions in a design system: color values, spacing units, font sizes, line heights, border radii, shadow definitions, and animation durations. They are not decisions about components - they are the decisions that components are built from. A token is a named variable: `color-brand-primary: #7C3AED`. That single token, referenced throughout the system, means that changing the brand color is a one-line change, not a find-and-replace operation across hundreds of components.

Tokens are structured in two tiers. Global tokens are the raw values (the actual hex codes, pixel values, milliseconds). Semantic tokens are the contextual aliases that give tokens meaning: `color-interactive-default` might reference `color-brand-primary`, but its semantic role is "the default color of interactive elements." This separation is what enables theming - a dark mode, a high-contrast mode, or a white-label product skin changes semantic tokens, not global ones.

Layer 2: Component Library - Reusable UI Primitives

Components are the building blocks of UI: buttons, inputs, dropdowns, modals, cards, navigation bars, tooltips. In a design system, components are not one-off designs - they are documented, parameterized, tested units that can be composed into any interface the product needs. Each component has a defined set of variants (size, state, hierarchy), a defined set of props (the inputs that control behavior), and a clear specification of when to use it and when not to.

The key architectural detail is that design components and code components must be in sync. A Figma component that is not mirrored in the React (or Vue, or Angular) codebase is not a design system - it is a design file. The moment a designer uses a component that does not exist in code, or a developer builds a component that is not in Figma, the system begins to diverge. The strictest design systems use automated tools (Storybook, Chromatic, Tokens Studio) to enforce this synchronization.

Layer 3: Pattern Library - Composed Solutions

Above components sits the pattern library: documented solutions to recurring UI problems. A pattern is not a component - it is a composition of components that solves a specific interaction challenge. The empty state pattern tells designers and developers how to handle a view with no data. The error recovery pattern specifies how the system communicates failures and what actions users can take. The data table pattern defines column sorting, pagination, row selection, and inline editing behavior.

Patterns are the most valuable layer for shipping speed. A team without pattern documentation solves the same UI problem fresh every time - in different ways, with different outcomes, creating inconsistency that erodes the user experience over time. A team with a pattern library reaches for the documented solution, ships faster, and produces a product that feels coherent even when built by many hands.

Layer 4: Documentation - The System's Interface

A design system that is not documented is not a system - it is institutional knowledge that lives in the heads of whoever built it. Documentation is the interface through which every designer and developer accesses the system without needing to ask someone. It covers: when to use each component, when not to, what the props control, what accessibility requirements apply, and how the component behaves across responsive breakpoints.

The best design system documentation is built in Storybook (for code) and Notion or Zeroheight (for the design rationale and usage guidelines). The goal is that a new designer or developer joining the team can get up to speed on the system in hours, not weeks - and that senior engineers are freed from explaining the same patterns repeatedly. This directly maps to what how a website is built start to finish looks like when a design system is the foundation.

Layer 5: Governance - How the System Stays Alive

The governance model is what separates a design system from a snapshot. Without governance, the system is updated once at launch and then diverges from reality as the product evolves. With governance, there is a defined process for: proposing new components, reviewing and approving changes, deprecating outdated patterns, and communicating changes to the teams that use the system.

TTGC Global recommends a model in which the design system team (or the individual system owner on smaller teams) owns contribution reviews, a versioned changelog documents every update, and a Slack channel or equivalent surfaces breaking changes before they reach product teams. The governance cost is small. The cost of a system that teams stop trusting - and start working around - is large.

A design system without governance is a design system with an expiration date. The token layer and the component library are the product - but governance is the maintenance contract.