Color theory tells you how colors relate. Applying color in UI design is a different skill — it's about assignment, restraint, and consistency. How much color is too much? Where should it go? How do you build a palette that works across every state and context your interface needs?
The effectiveness of a color palette is contextual: what works depends on the brand, the content, and the audience. So rather than prescribing specific hues, this guide focuses on the process of applying color systematically.
The 60-30-10 principle
A useful starting framework for color distribution:
- 60% — Dominant. Your background color and large surface areas. Usually a neutral (white, off-white, dark gray in dark mode). This is the canvas that everything else sits on.
- 30% — Secondary. Supporting elements: cards, sections, secondary backgrounds, text. Often a variation of your neutral palette or a muted version of your primary.
- 10% — Accent. Your primary brand color, calls to action, interactive elements, key indicators. This is where your most saturated color lives, and its scarcity is what gives it impact.
This isn't a rigid formula, but it captures an important principle: color is most effective when it's scarce. A primary button on a mostly-neutral interface pops. The same button in a rainbow of competing colors disappears.
Functional color roles
Beyond the 60-30-10 distribution, every color in a UI should have a defined role:
- Text colors — primary (high contrast, body text), secondary (medium contrast, supporting text), disabled (low contrast, inactive elements)
- Background colors — primary surface, secondary/elevated surfaces, overlay backgrounds
- Border colors — default, muted, focus ring
- Interactive colors — default, hover, active, focus, disabled states for links, buttons, and form elements
- Feedback colors — success, warning, error, info — each needing their own set of background, text, and border values
When you define these roles explicitly, you can map your entire palette to a set of semantic tokens. This is how color scales from a single page to a product with hundreds of screens — the system makes the decisions, not individual designers on each screen.
Dark mode isn't just inverting colors
A common mistake is treating dark mode as "swap white and black." A well-designed dark theme requires its own set of deliberate decisions:
- Surface colors use dark grays, not pure black (#000). Pure black creates too much contrast with text and can feel harsh on OLED screens.
- Elevation is communicated through lighter surfaces rather than shadows. A card that's 1 step lighter than the background reads as "above" it.
- Saturation often needs to decrease for brand colors. Fully saturated colors on dark backgrounds vibrate and can fail accessibility.
- Contrast ratios need to be re-verified. A color pair that passes at 4.5:1 in light mode may not pass in dark mode.
If your color system is token-based, dark mode becomes a theme swap rather than a redesign. Each semantic token maps to a different value in the dark theme, and the components never need to change.
How much color is too much?
Ask what job each color is doing. If a color doesn't serve a specific function — hierarchy, feedback, branding, interactivity — it's decoration, and decoration competes with function.
A practical test: can you remove a color and still understand the interface? If removing a teal accent from a card header doesn't reduce comprehension, that teal was decorative. Decorative color isn't always wrong, but it should be deliberate, not accidental.
In data-heavy interfaces (dashboards, analytics, admin tools), color budget is especially tight. Every hue you use for decoration is one less hue available for data encoding. Save your color variety for the things that need to be distinguished from each other — chart series, status indicators, category labels.
Testing color in practice
Color decisions should be tested in context, not in isolation:
- Test with real content — placeholder content is uniformly gray. Real content has images, varied text lengths, and user-generated elements that interact with your palette.
- Test across states — a button color needs to work in default, hover, active, focus, and disabled states. That's five values per button variant.
- Test across themes — if you support light and dark mode, verify every color in both.
- Test with accessibility tools — browser DevTools can simulate color blindness modes. Check that your functional colors (especially error/success) are distinguishable under deuteranopia (red-green color blindness).
- Test on multiple displays — what looks correct on your calibrated monitor may look washed out on a laptop screen or oversaturated on a phone.
Color in UI design isn't about picking beautiful colors. It's about building a system of functional color roles, constraining the palette to what the interface actually needs, and encoding those decisions in tokens so they scale. Beauty emerges from the system working well — not from adding more hues.