A design system is tested the day the brand changes. If a new colour or typeface means rebuilding every component, the system was describing one visual style rather than the product underneath it.
Separate structure from style
Components should describe behaviour and hierarchy: what is primary, what is secondary, what responds to input. Colours, radii, and type choices belong to a layer that can be swapped without touching that logic.
When those two layers are mixed, every visual update becomes a refactor. When they are separate, a rebrand is mostly a change of values.
Name things by purpose
A token called blue-500 tells you nothing once the brand is no longer blue. A token called action-primary still makes sense after the change.
Purpose-based names take longer to agree on, but they are the reason a system can outlive its first palette.
If a name describes how something looks, it will expire with the look.
Test with a second theme early
The cheapest way to find hidden dependencies is to build a second theme before you need one. Even a rough alternative palette exposes components that hard-code values.
Fix those early, while the system is small, and the eventual rebrand becomes a planned update instead of an emergency.
- Create a deliberately different test theme.
- Switch it on across key screens.
- Log every component that does not follow.
- Fix the token, not the component.
