Most design systems fail at adoption. Not because they were built wrong, but because they were built in the wrong order.

The pattern looks like this: a product team decides they need a design system. They start building components. They go deep on a beautiful card component, a sophisticated modal system, a navigation structure with every edge case handled. Three months later, they have 40 components that engineers barely use because the foundational tokens those components depend on were never properly defined.

Build order matters enormously. Here's what to build first, and why.

Why Most Teams Get the Order Wrong

The instinct when building a design system is to start with what's visible. Cards, modals, tables, navigation bars, these are the things designers and engineers interact with every day, so they're where attention naturally goes.

But components depend on foundations. A button component that uses a hardcoded hex color instead of a design token is technically a component, but it's not a design system component, it's a design pattern that happens to be documented. When the primary color changes, every one of those hardcoded buttons has to be updated individually instead of cascading from a single token change.

The foundation has to come first. Specifically, six foundational pieces that everything else depends on.

Layer 1: The Foundation

1. Color Tokens

Color tokens are named variables that represent your color decisions. Not #EE4D87, but color-brand-primary, color-feedback-error, color-neutral-300, color-surface-card. The actual hex values are assigned to those token names, and components reference the token names rather than the raw values.

This matters because it creates a single source of truth for every color decision in the system. When a color changes, brand refresh, accessibility improvement, theming for a dark mode, you change the token value and every component using it updates automatically. Without tokens, color changes require finding every hardcoded value across every component.

Token structure matters. A good token system has semantic tokens (which describe function, like color-feedback-error) that reference primitive tokens (which describe the actual color, like color-red-500). This lets you remap the semantic token without changing the component that uses it.

2. Typography Scale

A documented typography scale is not just "we use these three fonts." It's a complete system of named text styles: heading-xl, heading-lg, heading-md, body-default, body-small, caption, label, and so on. Each style specifies font family, weight, size, line height, letter spacing, and any responsive adjustments.

Without a defined typography scale, design and engineering make independent typographic decisions that slowly diverge. Text sizes drift. Line heights get set to arbitrary values. Different designers make different calls on the same UI pattern. The product stops feeling coherent.

With a defined scale, everyone pulls from the same set of named styles. Typographic decisions are made once, at the system level, and applied consistently everywhere.

3. Spacing System

Spacing is one of the most impactful and most neglected design system foundations. Without a defined spacing system, every designer is making independent calls about padding, margins, and gaps, and those calls slowly diverge across the product.

A spacing system defines a scale of named spacing values: space-1 (4px), space-2 (8px), space-3 (12px), space-4 (16px), space-6 (24px), space-8 (32px), and so on. Components reference these values rather than arbitrary pixel counts. The result is a product where spatial relationships feel consistent and considered, because they are.

The 4px base grid is the most common starting point because it aligns with most platform conventions and scales cleanly. Whatever base you choose, define it explicitly and use it everywhere.

Layer 2: Core Components

With the foundational tokens in place, core components can be built properly, as token-dependent, documented, governed components rather than ad-hoc patterns.

4. Button States

Buttons are the most-used interactive element in any product. They also have the most states: default, hover, focus, active, disabled, loading. Each state needs to be explicitly designed, not assumed.

Start with your primary button (your main CTA), secondary button, and tertiary/ghost button. Define every state for each. Document when to use which type, not "use primary for important actions" but specific guidance about which actions in your product are primary.

This sounds basic. But an undocumented button system is one of the most common sources of visual inconsistency in products. Every engineer makes their own call about the hover state. Disabled buttons look different across four different flows. The loading state was designed once and then forgotten.

5. Form Elements

Input fields, dropdowns, checkboxes, radio buttons, toggle switches, error states, helper text, placeholder behavior, label positioning, form elements have enormous surface area and enormous inconsistency risk.

Define the complete form element library before shipping any complex form-heavy flow. The cost of retrofitting a form system onto an existing product with inconsistent form patterns is extremely high. Building it first makes every subsequent form a matter of assembly rather than re-decision.

Error states deserve special attention. They're typically designed last and under time pressure, which is why they so often look different from everything else. Design error states with the same care as the default state.

6. Icon System

Icons need to be defined as a system, not accumulated individually. That means a consistent size scale (typically 16px, 20px, 24px), consistent stroke weight, consistent corner radius, and a consistent naming convention.

The naming convention matters for engineering adoption. Icons named arbitrarily or inconsistently are harder to find and reference. A systematic naming scheme (icon-arrow-right, icon-check, icon-chevron-down) is scannable and predictable.

Establish early whether icons will be SVG sprites, individual SVG imports, or a dedicated icon font. The technical implementation choice affects how they're maintained and updated.

What to Build Next

Once the six foundational components are in place and being actively used, Layer 3 patterns become much faster to build because they're assembling documented components rather than making new foundational decisions.

Cards, the most common content display pattern, with significant variation in context. Build the card component after your spacing and typography tokens are set so the internal spacing and text treatment is token-driven.

Modals and dialogs, define the overlay pattern, the close behavior, the heading/body/footer structure, and the sizing scale. Modals built without a defined pattern tend to proliferate in inconsistent forms across a product.

Navigation, top navigation, side navigation, and mobile navigation each need explicit treatment. These patterns are used on every page, so inconsistency here compounds everywhere.

Data display, tables, lists, stat cards. These need special attention in data-heavy products. Typography and spacing choices have outsized impact on readability in dense data contexts.

Common Design System Mistakes

Building too much too fast. A design system that covers every edge case immediately is also a design system that took so long to build that engineers started building around it. Start with the six foundational pieces. Use them. Iterate.

No governance. Who decides when a new component gets added? Who reviews and approves changes? Who's responsible for keeping Figma and code in sync? Without governance, design systems drift into inconsistency the same way undocumented products do.

Never adopted by engineering. The most common design system failure. Designers used it, engineers didn't, the product diverged. This is almost always a collaboration failure at the beginning, engineering needs to be part of defining the token naming conventions, component API decisions, and documentation format. Systems built with engineering get adopted. Design systems handed off don't. If you're unclear on when a design system makes sense in the first place, the product design process guide covers where it fits in the broader build sequence. Jamm builds cross-functional collaboration into every system engagement for this exact reason.

Documentation that lives nowhere anyone checks. Notion pages that aren't linked, Figma files that aren't referenced in tickets, Storybook instances that engineering doesn't know exist. The documentation location matters as much as the documentation quality.

How to Maintain a Design System Over Time

A design system is not a project, it's a product. It needs an owner, a roadmap, a feedback channel, and a governance process.

The most important maintenance practice: audit the system regularly against the actual product. Patterns in the product that aren't in the system are a signal that the system is incomplete. Components in the system that aren't being used are a signal that they're either redundant or poorly documented.

Version control and changelog discipline matter more at scale than they do when you're building. When the system is the source of truth for multiple engineering teams, knowing what changed and when is essential for debugging and alignment.

How Jamm Builds Design Systems for Product Teams

Jamm's product design work includes design system buildout as a core service, not as a separate engagement, but as part of the ongoing subscription. That means teams get a design system that evolves alongside the product rather than one that was built in a sprint and then abandoned.

The sequencing approach is always the same: foundation first, core components second, patterns third. And the engineering collaboration piece is built into the process from the start, because a design system that doesn't get adopted didn't solve the problem it was meant to solve.

Book a call with Jamm to talk through your current design system situation and where to start.

Start your design subscription and get your design system foundations built in the right order.