Modern Web Design Systems: From Tokens to Shipped UI

A design system is the shared language a team uses to build interfaces. Done well, it makes products feel coherent, accelerates development, and bakes accessibility and quality into every screen by default. Done poorly, it becomes a stale Figma file nobody opens and a component library everyone works around. The difference is rarely the components themselves — it is the structure, documentation, and governance around them. Here is how the pieces fit together.

Start With Design Tokens

Tokens are the foundation. Instead of scattering hex codes and pixel values through your code, you name every design decision and store it once. A color is not #7c3aed in forty places — it is color-primary, defined once and referenced everywhere.

:root {
  --color-primary: oklch(0.55 0.22 295);
  --space-4: 1rem;
  --radius-md: 0.5rem;
  --font-size-body: 1rem;
}

Tokens unlock three things. First, consistency — every component pulls from the same source. Second, theming — swap a token set and you have a dark mode or a white-label variant without touching component code. Third, a shared vocabulary between designers and developers, so a conversation about "primary" means the same thing in both Figma and the codebase. Organize tokens in tiers: primitive tokens (raw values), semantic tokens (color-text-primary, color-surface), and component tokens where needed. Semantic tokens are what components should reference, so you can change the underlying value without rewriting consumers.

Build Accessible, Composable Components

Components turn tokens into reusable UI. The best modern approach is to build on a foundation of accessible, behavior-only primitives — the headless components that handle focus management, keyboard interaction, and ARIA attributes — and apply your own tokens and styling on top. This gives you the visual identity you want without reimplementing the genuinely hard parts of accessible menus, dialogs, comboboxes, and date pickers.

Design components to compose rather than configure. A button that accepts thirty props to cover every variant becomes unmaintainable. Prefer small, composable pieces and a few clear variants:

<Button variant="primary" size="md">Save</Button>
<Card>
  <Card.Header>Title</Card.Header>
  <Card.Body>Content</Card.Body>
</Card>

Every component should ship with sensible defaults, documented props, loading and empty states, and full keyboard support. The goal is that using a component correctly is the path of least resistance.

Document So People Actually Use It

A component that is not discoverable does not exist. Documentation is what turns a folder of components into a system people reach for. Good documentation includes:

• Live, interactive examples showing each component in its real states.
• Usage guidance — when to use this component and when to use a different one.
• Code snippets that can be copied directly into a project.
• Accessibility notes describing keyboard behavior and ARIA semantics.

Tools that render components in isolation alongside their props and variants make this documentation living rather than static, so it never drifts from the real implementation. The test of good documentation is simple: a new developer should be able to build a correct, on-brand screen without asking anyone a question.

Keep Design and Code in Sync

The most common failure mode is divergence — the Figma library and the coded components slowly drift apart until designers and developers are working from different realities. Tokens are the primary defense, because when both tools reference the same token names, a change propagates to both. Some teams go further and generate code tokens directly from their design tool exports so there is a single pipeline from design decision to shipped CSS variable.

Govern the System

A design system is a product with internal customers, and like any product it needs ownership and a process for change. Decide how new components get proposed, reviewed, and added. Decide how breaking changes are versioned and communicated. Decide who reviews contributions for consistency and accessibility. Without this governance, two developers solve the same problem two different ways and the system fragments.

Governance does not have to be heavy. For a small team, it might be a single owner and a short contribution checklist. For a larger organization, a federated model lets product teams contribute while a core team maintains standards. What matters is that the process exists and is followed.

Common Pitfalls

• Building components before tokens. You will hard-code values you later have to refactor. Establish the token layer first.
• Over-engineering early. Start with the components you need now. A system that anticipates every future case ships nothing.
• Treating it as a one-time project. A design system is maintained continuously or it dies. Budget for ongoing ownership.

Conclusion

A modern design system is a layered thing: tokens at the base, accessible components above them, living documentation around them, and governance holding it together. Each layer reinforces the others — tokens make components consistent, documentation makes them usable, and governance keeps the whole thing healthy as it grows. When we set up design systems for clients at Codememory, we start with tokens and accessibility because those decisions are the hardest to reverse later, and they are what let a small team ship UI that looks and behaves like the work of a much larger one.