Structuring color tokens for a new app

WHAT THIS TESTS This evaluates whether you understand layered token architecture and the reasons separation pays off, not just naming a few colors.

A GOOD ANSWER COVERS Structure colors in tiers. The primitive or base tier is the raw palette: scales like blue-100 through blue-900 and neutral grays, defined as concrete values with no meaning attached. The semantic tier expresses role and intent by referencing primitives: text colors like color-text-primary and color-text-muted, background and surface colors, border colors, brand and action colors like color-action-primary, and state or feedback colors for success, warning, error, and info. An optional component tier defines component-specific tokens, such as button-background, that point at semantic tokens. Components and screens consume semantic tokens, never raw primitives. Separation matters because it decouples meaning from value: you can add a dark theme by remapping semantic tokens to different primitives, rebrand by swapping the palette, and ensure consistent, accessible contrast, all without editing component code. It also makes intent self-documenting and changes safe and centralized.

COMMON WRONG ANSWERS A single flat list of named colors. No semantic layer, so theming requires editing components. Mixing raw hex into components. Forgetting state and feedback colors. No path to dark mode.

LIKELY FOLLOW-UPS How does this enable dark mode? Why not let components use primitives? Where do accessibility and contrast checks fit?

ONE CONCRETE EXAMPLE Primitive tokens define gray-900 and blue-500. Semantic tokens set color-text-primary to gray-900 and color-action-primary to blue-500. A button uses color-action-primary. For dark mode, you remap color-text-primary to a light gray and surfaces to dark primitives, and every screen updates correctly with no component changes.