Color in Interfaces

Color in an interface is a signaling system before it is a style. A destructive button is red because red warns, not because red looks good beside the header. A disabled field is muted because muted means unavailable. A progress bar fills with the brand color because that color has been taught to mean this product. Every color in a working interface should be answerable to a question: what does this one mean, and where else does it mean the same thing? That discipline is what separates an interface palette from a mood board. It also produces a practical consequence — colors get named for their job, such as surface, border, text-secondary, or danger, rather than for their appearance — so that the same meaning can be rendered differently in different contexts without the meaning changing.

Interfaces present far more information than a person can read, so they need a channel that works before reading does. Color is that channel. A glance across a dashboard tells you something is wrong before you have parsed a single label, because one row is not the color of the others. But that pre-attentive power comes with a cost. Color is perceived relative to its surroundings rather than absolutely, so the same value can read as loud on one background and invisible on another. A significant minority of men have some form of color vision deficiency, most commonly affecting the distinction between red and green. And screens render color differently from one another. These facts turned interface color from a matter of taste into a matter of specification, measurement and testing.

• →A form field that turns red with an icon and a written message when validation fails, so the error is carried by three channels rather than by hue alone.
• →A semantic token named color-surface-raised that resolves to near-white in the light theme and a light gray in the dark theme, letting one component definition serve both.
• →A status column in an admin table where color is paired with a text label, so a user who cannot distinguish the hues still reads the state correctly.
• →A chart whose categorical series are distinguished by lightness steps and shape markers as well as hue, so it survives being printed in grayscale.

For most of design history color meant pigment: mixed physically, and subtractive, because each added ink absorbs more light. Print standardized on the CMYK process, where the paper supplies the white. Josef Albers, teaching at Yale and publishing Interaction of Color in 1963, demonstrated that color is perceived relationally — the same swatch appears to change when its surroundings change — a finding that remains the single most useful thing a designer can know about color. Screens inverted the physics: RGB is additive, built from emitted light, so black is the absence of signal. Early interfaces had tiny fixed palettes dictated by hardware. As displays improved, the constraint shifted from what a screen could show to what a person could reliably distinguish.

Google's Material Design, introduced in 2014, popularized systematic palettes with numbered tonal steps and used color and shadow together to express elevation. That approach evolved into token-based theming, now common across design systems: a component references a semantic token, and a theme supplies the value. Dark mode, which arrived as a system-level setting users could choose, made this indispensable — and made clear that a dark theme is a second palette, not an inversion. Inverting a light palette produces harsh, vibrating results, because pure white text on pure black strains the eye and saturated colors glow against dark surfaces. Dark values must be re-derived, usually by desaturating accents and using layered near-blacks. Wide-gamut P3 displays added further range, and with it the need to specify fallbacks.

Consider an airline's seat map. Available seats, selected seats, extra-legroom seats, and unavailable seats must be distinguished instantly by thousands of travelers on every kind of screen. If the team encoded those four states only by hue — green, blue, purple, gray — a passenger with red-green color deficiency might book the wrong seat, and anyone on a sun-washed phone might too. A well-built seat map varies lightness as well as hue, outlines the selected seat with a border, marks extra-legroom seats with an icon, and renders unavailable seats with a lower-contrast fill plus a strike pattern. Each state then survives grayscale, glare, and color deficiency. The color still carries the message faster than words, but it is no longer the only thing carrying it.

• →Give every interface color a job; if you cannot name what it means, it probably does not belong in the palette.
• →Never encode meaning by hue alone — pair color with text, icon, shape or position so the signal survives color vision deficiency and grayscale.
• →Meet contrast requirements deliberately: WCAG 2.x asks for at least 4.5:1 for normal text and 3:1 for large text against its background.
• →Use semantic tokens rather than raw hex values in components, so themes can change without touching every component.
• →Treat dark mode as a second palette with re-derived values, not an inversion of the light one.
• →Remember that color is perceived relative to its surroundings, so test every value in the context where it will actually appear.