Color Palettes in B2B Design Systems: How to Build a Scalable and Manageable Color Architecture

Color in B2B products is never as simple as picking a few brand shades. Enterprise interfaces work with complex data structures, system states, and dense information. This means the palette must be not only visually consistent but also technically structured, scalable, and ready for long-term evolution.

Below we explore which color groups you need, how to organize the architecture of shades, and why a well-designed palette is essential for designers, product leaders, and teams building design systems.

Two Key Color Groups

Most enterprise products rely on two main color categories:

• Core interface colors (Primary) - Used in the most common component states: backgrounds, borders, buttons, interactive elements.
• Status or marker colors (Secondary) — Used to display alerts, warnings, success states, risks, or to highlight specific data points.

It might feel like only a handful of colors is enough. In reality you need a structured system, not a simple list. This is where tokenization and proper shade architecture come in.

Why Structure Matters

Tokenization requires each color to be represented by a full scale of shades. The most common format is 100 to 900, with a step of 100. This nine-step model has become a de facto industry standard because it is predictable, easy to use, and scalable.

This structure gives another big advantage: it simplifies theme switching. To create light and dark themes, you usually map “opposite” shades within each color. For example:

• Light theme uses 200 → Dark theme uses 800
• Light theme uses 400 → Dark theme uses 600

However, this mechanical mapping does not always deliver the best result. Sometimes you need manual tuning to maintain balance and accessibility.

Technical Requirements for a Reliable Palette

To make your palette truly functional, consider these fundamentals.

Even gradient steps

Build a gradient from the lightest to the darkest shade, split it into equal segments, and take shades from the center of each segment. This ensures consistent optical steps across the palette.

Visible differences between neighboring shades

Shades must remain distinguishable even on screens covering up to 85% of the sRGB space, which is still common in enterprise environments. Find such a device and test the palette on it.

Contrast requirements

For text on colored backgrounds, follow WCAG:

• AA: contrast ratio 3.0 or higher
• AAA: 4.5 or higher

Check the contrast of this color against black (#000000) in the first half of the gradation and against white (#000000) in the second half. If your design specifies other base colors for text, it is better to use them for this check. Please note that the contrast check tool is already built into Figma. Also note that WCAG distinguishes between normal text and headings, with much higher requirements for the former.This becomes especially important for system statuses, alerts, and any color-dependent information.

A situation may arise where the shade does not meet the contrast requirements for either black or white, especially at the AAA level. In this case, it should only be used for filling elements that do not contain text or icons.

Because of these factors, separate color pairs for light and dark themes often work better than relying solely on automatic shade inversion.

How to Work With the Palette

Below is a practical, Figma-friendly structure that scales well for enterprise design systems.

Wide Palette: The Foundation

This is the level where hue groups are defined. Keep the naming simple:

• Red
• Blue
• Yellow
• etc...

In Figma, create a Colors collection and a Wide palette section. Each color gets its own subgroup, each shade its own variable with HEX values.

Even if you are not planning multiple themes, you will almost certainly need at least a dark theme. Create an additional variable mode and define how each shade behaves when the theme switches.

Base Palette: Semantic Colors

Next comes the Base palette. These colors carry meaning in the interface.

Semantic names reflect the purpose:

• Primary
• Accent
• Success
• Warning

Grayscale can use numeric naming consistent with the wide palette.

Typical group sizes:

• Primary: 4–10 shades
• Accent: 5–10 shades
• Grayscale: 4–13 shades

Values in this layer reference Wide palette shades.

Context Palette: Colors for Component States

This level connects color semantics to real interface behavior. Here you define variables for:

• button states
• focus and hover states,
• borders and backgrounds,
input states, validation statuses, data states and alerts.

These variables should reference the Base palette. If the required shade is not available there, use the Wide palette.

This is the layer applied directly to components in Figma. It completes the hierarchy: shades → semantics → component behavior.

The result is a flexible and predictable color architecture that scales with your product.

Final Thoughts

A well-structured palette is more than a list of colors. It becomes an essential part of the design system’s architecture, supporting consistency, accessibility, and long-term product growth.

You can explore more about variable-based workflows in Figma’s documentation, but the model above gives everything you need to build a robust and scalable palette.