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.
