Color sets the tone, guides attention, and strengthens brand identity. But without structure, it can create inconsistency and confusion. This article explores how smart color systems bring clarity and scalability across products and teams.

Contributors

By Polina Reut, Hanna Matsiyeuskaya and Ilya Greben

from Design Systems Surf team

What makes color so important in design

Before you get into tools or naming rules, it helps to take a step back and think about what color actually does in a product. It’s not just decoration. Color brings structure to the screen, guides attention, shows what’s interactive, signals success or error, and helps products feel consistent and recognizable. It also shapes how people feel when they use your product — calm, focused, playful, or alert.

But when colors are chosen at random or used inconsistently, things quickly become confusing. A single style might mean one thing in one place and something completely different elsewhere. Changing a color in one part of the interface might accidentally affect another. As your product grows or more people join the team, these problems only get worse.

That’s why even a basic structure, with clear roles for each color and guidance on where to use them, can make a big difference. A well-organized system doesn’t limit creativity. It helps you maintain it as your product grows.

Anatomy of a Color System

You don’t need a full token setup to build a clear color system. What matters is the thinking behind your colors, not the way they’re stored.

A strong design system color palette typically includes these layers, providing both semantic meaning and UI relevance across tokens in Figma.

Base Palette

The core colors such as brand hues, grays, and neutrals, usually defined across a range of tints and shades.

Semantic Colors

These assign meaning to colors, such as error, success, or info. You might label them semantically in your design files or simply refer to them that way in team documentation.

Usage or Contextual Styles

These answer the question “Where is this color used?” For example, in backgrounds, buttons, borders, or icons.

A bit of structure goes a long way. Even something as simple as ten well-named, consistently used styles in Figma can bring clarity and prevent the kind of mess that happens when every color decision is made in isolation.

Imagine you haven’t set up a complex token system yet, but you do have a clear color structure. That alone can bring order to your design process.

You might start with a base palette: five shades of your brand blue, a range of grays for text and backgrounds, plus a couple of neutrals. These get saved as Figma styles like blue-500, gray-100, and neutral-200.

Next comes the semantic layer. Let’s say you use red-600 for error messages and name it error-default. Even though the style still points to red-600 in Figma, it now has meaning. It’s no longer just a shade of red; it’s the designated error color.

Finally, you add contextual styles. That same error-default might become border-error or bg-error-subtle, depending on where and how it’s used. Each style now answers not just “what color is this?”, but “what’s it for and where does it belong?”

The result is a color palette that’s structured, scalable, and easy to explain to the team, without needing to dive into full-blown token complexity. Most importantly, you avoid the chaos that comes from every designer inventing their own shades.

Naming, structuring, and scaling

Naming is more than semantics — it’s infrastructure.

Without clear, consistent naming, even the most well-chosen colors can become a source of confusion. One designer calls it primary, another says main, someone else names it accent or 01. Everyone ends up interpreting it differently.

Mature design systems rely on a naming convention that reflects four key attributes, following the structure used in Figma and modern UI codebases:

Category-Intent-Variant-State

Examples

bg-primary-default the default background color for primary elements
text-alert-subtle-hover a soft alert color for text on hover
border-neutral-strong a stronger neutral color for borders

Let’s say you’re defining the hover background of a secondary button. Instead of something vague like blue-200-hover, you name it: bg-secondary-default-hover

Here’s how it breaks down

bg = category (used for backgrounds)
secondary = intent (this style applies to secondary buttons)
default = variant (the default version, as opposed to success or danger)
hover = state (applies on hover)

This structure scales easily. Want to add an active or disabled state later? You don’t need to invent a new system. Just follow the same logic and add states like active, disabled, or anything else you need.

Most importantly, this makes your system understandable and maintainable. It’s easy to teach, easy to document, and easy to sync between Figma and code. When a developer sees text-alert-subtle-hover, they instantly recognize it as text.alert.subtle.hover in code. No guessing, no misalignment.

Without this kind of structure, designers start naming things however they want, and developers are left to interpret what was meant. It’s not about being “correct.” It’s about making the same logic work across different brains.

Accessibility: beyond just contrast

When it comes to accessibility, most designers tend to think of just one thing: contrast. Check your colors against WCAG, make sure the text is readable and the job feels done.

But in reality, this is just the starting point.

Here’s what to aim for:

Aim for at least 4.5:1 contrast for normal text
Use 3:1 for large or bold text
Check combinations like text on buttons, icons on backgrounds, or states like hover and disabled

But contrast is just one piece. Accessible systems also avoid using color as the only signal. A red outline might not be enough, so pair it with an icon, a message, or an underline. And remember, not everyone sees color the same way. Use colorblind simulators and double-check key UI elements like errors, links, and success states.

Still, accessibility goes beyond color.

It’s not just about whether something is visible — it’s about whether it’s usable. Interfaces need to work well in different states, under various conditions, and for users with different abilities or ways of processing information.

Contrast is the starting point. But if you want to build a truly inclusive system, here’s what else to consider:

Focus and navigation

Do all interactive elements have a clear focus state? Is it obvious where the user is when navigating with a keyboard?

States and differentiation

Can users easily tell the difference between hover, active, disabled, and selected? Or are the variations too subtle to notice?

Size and readability

Does your typography scale well across screen sizes? Is the text still readable when zoomed in?

Meaning beyond color

If someone can’t distinguish red from green, will they still understand what’s happening? Are icons, text, or other visual cues reinforcing the color signals?

For example: you might have a button with perfect contrast, but the focus ring is a barely visible outline. A keyboard user won’t know where they are. And a low-vision user may not even realize it’s interactive.

Now flip it: the button has a strong focus ring, a visible hover state, and a clear icon or label that explains its purpose. It’s legible, perceivable, and functional for more people, in more contexts.

Accessibility doesn’t require a huge system. It just requires thoughtfulness and testing.

Design system color palette in practice

There’s no one-size-fits-all approach to design system color palettes, but real-world examples show how the best colors for user interface consistency can be applied at scale.

USWDS (U.S. Web Design System)

Designed for government websites, USWDS emphasizes clarity and accessibility. It organizes colors by purpose, such as foreground, background, and borders, and includes clear guidance on usage and contrast. Instead of focusing on brand-driven palettes, it prioritizes function, which makes it a great fit for high-trust, high-clarity environments.

Material 3 (Google)

The latest version of Material Design introduces dynamic theming. Instead of using a fixed set of colors, it creates semantic palettes based on user preferences or system themes, such as Android’s wallpaper-based Material You. This approach requires a well-structured token system, but it allows for more personalized and consistent experiences across the interface.

Wise

Designed by Wise, this system keeps things simple and vibrant with a strong green brand anchor (Bright Green, Forest Green) supported by energetic secondary accents like bright orange and yellow. It strikes a balance between brand identity and accessibility, making it both delightful and usable.

Polaris (Shopify)

Polaris uses a contextual and purpose-driven system that clearly separates brand color from utility. Tokens like surface-subdued, text-muted, and icon-disabled allow for consistent styling across admin interfaces and make it easy to apply different themes without rewriting logic.

Adobe Spectrum

Spectrum’s color palette spans multiple grayscale tints and shades of color, carefully structured for UI flexibility. The grayscale system supports neutral layouts that coexist with vibrant hues, all while maintaining accessibility standards.

IBM / Carbon

Built atop IBM’s design language, the IBM and Carbon Design Systems center around a core blue, extended into ten swatches with nuanced gradients and grayscale families. Every hue has 10 steps (light to dark), with guidelines for contrast, gradients, and color in UI contexts.

These systems differ in tone and scope, but all share one principle: color is a tool, not a decoration.

Common pitfalls to avoid

Even a simple color system can go wrong if there’s no shared logic behind it. Here are a few things to watch out for:

Assigning colors directly without a naming layer

Using raw hex codes in your components (or naming styles Blue-500, Red-1) makes it hard to know what the color is for. When one element needs to change, it risks breaking many others. Instead, name for purpose: Button Background, Error Border, Muted Text.

Lack of documentation

If someone new joins your team, how would they know which blue to use? Write it down. Even a short note like “Use this for primary buttons only” helps preserve consistency.

Designing without context

Colors need to work on real UI, not just in swatches. Test your styles inside buttons, form inputs, modals, and cards. See how they behave in light and dark modes, on hover and disabled states.

Over-engineering too early

Not every project needs 40 tokens or a full design-to-code handoff pipeline. If you’re working on a smaller product, keep it simple. Build the structure you need today and evolve it as your product grows.

Wrapping Up

A color system is one of the quiet forces behind great product design. When structured well, it helps teams work faster, communicate clearly, and scale with confidence. It supports accessibility, strengthens branding, and reduces design debt.

Before choosing a palette or naming a style, take a step back. Define what color means in your system and how it will scale. Plan for edge cases. Align with developers. And build for clarity, not just for today but for every screen and every contributor down the line.