Building a color system that survives a rebrand

Most design systems treat color as fixed brand constants, which means a rebrand forces a rebuild from scratch. A resilient token architecture separates structural roles from brand expression, so the system adapts to new colors without breaking components or accessibility contracts.

Systems Brand Tokens

Highlights

Systems that hardcode brand hex values into component tokens create a brittle chain — changing the primary color means auditing every component that references it, often manually.

A three-tier token architecture (primitive → semantic → component) lets you swap the primitive layer during a rebrand while semantic and component tokens remain stable.

The Brand Starter Kit ships with this three-tier structure pre-built, so teams can test rebrand scenarios by replacing the primitive palette without touching downstream tokens.

Why rebrands break design systems

The typical design system encodes brand colors as top-level constants: primary-500, secondary-300, neutral-100. Components reference these tokens directly, and accessibility checks are run against these specific values. When a rebrand introduces new colors, every reference needs to be audited — not just for visual consistency but for WCAG compliance against every surface combination. Teams that have built complex systems over 2–3 years often discover that a rebrand effectively means rebuilding the entire token layer, which defeats the purpose of having a system in the first place.

The three-tier token pattern

A more resilient approach separates tokens into three tiers. Primitive tokens are the raw color values — they have no semantic meaning and are named by hue and shade. Semantic tokens map primitives to roles: surface-primary, text-default, border-subtle. Component tokens reference semantic tokens for specific UI elements: button-background, card-border, input-focus-ring. During a rebrand, you replace the primitive layer and update the mapping from semantic to primitive. Component tokens never change because they only know about roles, not colors. This pattern requires more upfront work but pays for itself the first time the brand palette shifts.

Testing a rebrand before committing

The safest way to validate a new palette is to run it through the existing system in a staging environment before touching production tokens. Create a duplicate of the primitive layer with the new brand colors, re-map the semantic tokens, and render the full component library. Check contrast ratios programmatically — tools like axe-core or custom scripts against your token JSON can flag failures in seconds. The Brand Starter Kit includes a token structure designed for exactly this workflow: swap the primitive file, run the contrast audit, and review the visual diff. If everything passes, the rebrand is a single file change in production.

Newer issue

2026-04-30

Older issue

The designer's guide to earth tones in digital interfaces

2026-04-16