Color and component states: building interactive color systems

A button has more than one color. Every interactive element in a UI has at least four states — default, hover, active, and disabled — and each requires its own color specification. Building state colors deliberately, rather than picking them on the fly, is one of the highest-leverage decisions in UI palette work.

UI Design Color Systems Interactive Design

Highlights

Most interactive color problems are discovered in production, not design. Building a state color system before component-level work begins prevents thousands of micro-decisions from accumulating into inconsistency.

The lightness shift model — where hover lightens and active darkens relative to the base color — is the most reliable and visually predictable pattern for interactive state colors.

Disabled colors should be desaturated and reduced in contrast, but not invisible. A disabled element that disappears from view creates confusion; one that appears clearly inactive communicates intent.

The state color problem no one plans for

Most color systems are designed around rest states. The design file has the default button, the primary accent, the surface colors — and the palette feels resolved. Then the first prototype ships and the team starts discovering: what does this button look like on hover? What changes on press? What about disabled? In the absence of a plan, these decisions get made ad hoc, by whoever is coding the component at the time. The result is usually inconsistent: some hover states are slightly lighter, some are slightly darker, some use opacity, and some add a border. A deliberate state color system defines these relationships once, before component work begins, and enforces them across the product.

The lightness-shift model for interactive states

The most predictable pattern for interactive state colors is a systematic lightness shift relative to the base. In a light-mode interface, the progression typically looks like this: default sits at the base hue, hover shifts 8-12% lighter, active shifts 6-10% darker than the default, and focus adds a high-contrast ring rather than changing the fill. On dark surfaces — the Nocturne Tech palette is a useful reference here — this reversal in direction is especially useful: hover states shift slightly toward the base surface color (slightly lighter), while active states deepen toward a near-black. The pattern works because it aligns with physical metaphor: hovering is approaching (lighter, less committed), pressing is sinking (darker, more committed).

Disabled state color: the accessibility edge case

Disabled colors are the most frequently under-specified state. The instinct is to make them gray — and that is mostly right — but the implementation matters. A disabled element should be clearly distinguishable from an enabled element (reduced contrast, desaturated fill) but not invisible. WCAG does not require disabled elements to meet 4.5:1 contrast ratio, but elements that are too low-contrast will be missed by users, creating confusion about whether the option is gone or just unavailable. The Dark Mode UI Kit includes pre-specified disabled-state tokens for each component type, which eliminates the guesswork and ensures the UI communicates clearly even in edge states.

Newer issue

Saturation control: the underused variable in palette refinement

2026-09-10

Older issue

Seasonal palette shifts: how to adapt your core system for campaign content

2026-09-24