Roll out a design system color change

WHAT THIS TESTS Whether you understand a design system as a versioned dependency and can describe a safe propagation flow rather than a quick find-and-replace.

A GOOD ANSWER COVERS Start at the source of truth. Update the primitive blue token, not component CSS. If buttons reference a semantic token like color-action-primary, confirm whether you are changing the primitive that several semantics point at, since that has wider blast radius. Rebuild the platform outputs with the token transformer so CSS custom properties, and any native outputs, regenerate. Run automated visual regression tests to catch unexpected UI shifts and run accessibility contrast checks so the new blue still meets contrast against text and backgrounds. Bump the package version following semver; a visible color change is usually at least a minor release. Publish the package. The consuming application then updates its dependency version, runs its own tests, and redeploys.

COMMON WRONG ANSWERS Editing the hex directly in component files bypasses the token system and guarantees drift. Publishing without a version bump means consumers cannot control when they take the change. Skipping contrast checks can ship an inaccessible color. Ignoring components that hardcoded the old value, which will not update.

LIKELY FOLLOW-UPS What if the app pins an exact version? It will not get the change until it bumps. How do you catch components that bypassed the token? Lint for raw hex values. Major or minor version? Minor if backward compatible, major if it breaks consumers.

ONE CONCRETE EXAMPLE Design approves a new blue. You edit blue-600 in the token JSON, rebuild to regenerate var(--color-action-primary), and visual regression flags a low-contrast badge that also used blue-600. You repoint the badge to a darker primitive, publish version 2.4.0, and the app upgrades from 2.3.x, runs tests, and deploys. Any component that hardcoded the old hex is flagged by the lint rule and migrated.