Color and Contrast
Color is one of the first things people notice about an interface. It sets the mood, guides attention, and establishes trust. But color is also deceptively complex. A palette that looks great in mockups can fail when deployed to real devices, viewed in sunlight, or used by people with color vision deficiency. The responsibility of choosing color well extends beyond aesthetics to accessibility and usability.
A palette is not just a list of pretty hex codes. It's a system designed to answer questions before they're asked: What color signals danger? What color indicates success? How do I know which element is interactive? When every color choice has been thought through, the interface becomes easier to use, not harder to look at.
A palette is a system, not a whim
Many designers start by choosing colors they love, then wondering how to use them. A better approach reverses this: understand what the interface needs to communicate, then build a palette that communicates it.
A working palette earns its keep when it answers questions without explanation:
- Neutrals carry most of the surface area and set the overall mood.
- Accents are rationed so that when they appear, they always mean something.
- Semantic colors map to states (error, success, warning, info) and are never used for decoration alone.
Neutrals should do the heavy lifting. In most interfaces, about 80% of the visual area is neutral: backgrounds, text, borders, dividers. These colors need to work together to create hierarchy without being flashy. They should feel cohesive across light and dark themes without requiring separate definitions for every component.
A neutral scale works best when steps are mathematically predictable. If you jump between brightness levels randomly, hierarchy breaks down. Aim for a scale where each step is slightly darker or lighter than the last, with enough contrast to feel distinct but not so much that steps look disconnected.
Accent colors—your brand colors—should appear sparingly. They call attention. Use them on primary actions, to highlight important information, or to create visual brand recognition. If accent colors are scattered everywhere, they stop meaning anything. They become background noise. Design systems built on restraint feel more refined than those that treat every color as equally important.
Semantic colors are contracts
Red doesn't mean "bad" by accident. Through years of interface design, we've built a collective expectation that red indicates error or danger. A form validation error should be red. A destructive action should be red. When you break this pattern, you confuse people and force them to read more carefully.
Semantic colors—red for error, green for success, yellow for warning, blue for info—are contracts with your users. These associations run deep. People don't think about why a delete button is red. They just sense that it's dangerous. Honoring these patterns makes interfaces feel intuitive.
The challenge arises when semantic colors need to fit within your brand palette. Your brand might use orange, but if you use orange for everything including warnings, warnings won't feel distinct. This is where careful design comes in. You might use a vibrant orange for the primary action and a muted orange-red for warnings. Or you might accept that the best warning red isn't your favorite color.
Semantic colors should have clear roles:
- Error indicates a problem that blocks progress—usually bright red.
- Success indicates a completed task—usually green or a muted shade.
- Warning indicates a risk but not a blocker—usually yellow or orange.
- Info indicates neutral information—usually blue or a muted primary color.
Contrast keeps things readable
Color contrast is where aesthetics meet accessibility. A beautiful palette is useless if people can't read the text on top of it. The WCAG standard requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. In practice, aiming higher (7:1 or better) ensures your interface remains readable on older screens, in bright sunlight, or for people with moderate color vision deficiency.
Contrast is a contract with your users. When you place light text on a light background because you like the aesthetic, you're making a choice to prioritize appearance over legibility. Sometimes that's worth it. Often, it's a mistake that betrays a lack of testing on real devices and in real lighting.
The best approach is to test your palette on multiple devices and in multiple lighting conditions. A color that has great contrast on your monitor might fail on a phone screen or in direct sunlight. Testing catches these problems early.
Beyond luminance contrast, there's also color contrast—the saturation and hue differences between adjacent colors. Colorblind users might not distinguish red from green by hue alone, but they can distinguish them by brightness. This is why semantic colors need luminance contrast as well as color contrast. A red error message should also be darker than the background, not just a different hue.
Dark mode complicates palette design
Dark mode is no longer optional. More interfaces offer it every year. This means your palette has to work in both light and dark. Many teams make the mistake of simply inverting their palette—bright text on dark backgrounds, dark backgrounds become light—but simple inversion often fails.
The relationship between neutrals changes in dark mode. Your lightest neutral might become black, and your darkest neutral becomes white. This inverts contrast relationships. An element that's perfectly readable in light mode might fail in dark mode if you just invert the colors.
Better approach: design your palette in both modes simultaneously. Build a light palette and a dark palette with the understanding that they serve the same purpose. Each should maintain contrast ratios, semantic color meanings, and overall hierarchy. The colors themselves might be completely different—that's fine. What matters is that the system works.
Tools like color contrast checkers and palette generators can accelerate this work, but there's no substitute for looking at your actual interfaces in both modes and adjusting by eye.
Choosing a palette is iterative
You'll rarely get a palette perfect on the first try. Start with a concept—maybe inspired by nature, or a brand story, or a mood—then build a palette around it. Test it on real components. Refine based on how it feels in context.
Some good starting points for palette exploration:
- Look at interfaces you admire and reverse-engineer their color decisions.
- Use generators like Colordot or Coolors to explore variations.
- Test your palette with colorblind simulation tools to catch problems early.
- Solicit feedback from team members, especially those with color vision deficiency.
The palette is one of the most visible decisions in an interface. Get it right, and people won't think about color. Get it wrong, and color is all they think about—usually in frustration.