Building a Brand Color System: Architecture Over Aesthetics

Most designers approach brand color as a palette selection problem: choose a set of harmonious colors, document them in a style guide, and call it done. This is a palette, not a system. A color system is a structured architecture of color decisions, naming conventions, relationships, and governance rules that allows the palette to be applied consistently across every design surface, at any scale, by any team member. The difference between a palette and a system is the difference between a set of ingredients and a recipe — one requires judgment on every application, the other encodes that judgment into the structure itself. The foundation of a color system is a primitive layer: the full set of color values available to the brand, organized into named scales. A primitive color scale for a brand's primary blue might run from Blue 50 (near-white tint) through Blue 900 (near-black shade) in ten increments, each precisely defined in HEX/RGB/HSL. These values are not themselves the design decisions — they are the vocabulary from which design decisions are made. The primitive layer should be expansive: more values than you expect to use, covering the full range of possible applications. Above the primitive layer sits the semantic layer: named tokens that describe the purpose rather than the appearance of a color. `color.background.primary` might map to `neutral.100` in light mode and `neutral.900` in dark mode. `color.interactive.default` maps to `blue.600` at rest, `blue.700` on hover, `blue.800` on press. Semantic tokens decouple design intent from color values — a single semantic name can map to different primitives in different contexts (themes, modes, brands) without changing the meaning of the token. This is what enables multi-mode systems: you change the mappings, not the semantics. The component layer is where semantic tokens get applied to specific UI elements: `button.primary.background` uses `color.interactive.default`, which in turn uses `blue.600`. A designer working on a button doesn't need to know the hex value — they apply the right component token, and the system handles the rest. Changes made at the semantic level automatically propagate to all components. This three-tier structure (primitive → semantic → component) is the architecture of every mature design system, from IBM Carbon to Material 3 to Apple HIG. Brand color governance — the policies that determine who can introduce new color values, when tokens can be added, and how palette evolution is managed — is the under-discussed aspect of color systems. Without governance, systems drift: designers add ad-hoc hex values when primitives don't quite fit, semantic names get repurposed, component tokens diverge from the semantic layer. Effective governance requires both tooling (Figma Variables, Tokens Studio, Style Dictionary) and process: a color review workflow, a versioning strategy, and clear criteria for when the system should expand versus when designers should work within existing constraints.