From one brand color
to interface roles.

A logo may need one memorable color. An interface needs a coordinated set of colors for surfaces, text, actions, borders, focus, feedback, disabled controls, and interaction states. The mistake is assuming that the brand color—or a sequence of lighter and darker versions of it—already constitutes that system.

The real problem is assigning responsibility

Imagine a company whose brand color is a vivid orange. The orange works beautifully in its logo, but white text on that orange may not meet the contrast needed for a normal-size button label. Darkening it until white passes might produce a technically compliant button, yet the new shade may no longer feel like the brand.

That is not simply a palette problem. It is a decision problem: where must the original color remain unchanged, where can it be transformed, and where should a different color perform the job?

1. Choose the brand color’s first job

Begin by naming the most important interface role the color should play. In a software product, that is often the primary action. In an editorial product, it might be links or highlighted passages. In a luxury brand, the signature color may work better as a restrained accent than as a large background.

Do not assign it everywhere at once. If the same color represents actions, warnings, selected states, decorative shapes, and data categories, users cannot learn what it means. One deliberate role creates a stable anchor for the rest of the system.

Questions worth answering

• Where does recognition matter more than visual volume?
• Does the color need to carry text, or can it remain an accent?
• Will people understand it as an action, a status, or decoration?
• Does the role still work in dark mode and high-contrast contexts?

2. Establish the canvas and reading colors separately

The canvas and body text do most of the visual work in an interface. Choose them for sustained reading, hierarchy, and comfort—not simply because they resemble the brand hue.

A warm brand may benefit from a warm off-white canvas, but that relationship should be intentional. The body text can be a near-black with a subtle temperature rather than a fully saturated version of the brand color. This keeps large reading areas quiet and gives the brand color room to remain distinctive.

3. Derive states from behavior—not from a desire for more swatches

Once the primary role is known, add only the states required by actual components. A button may need default, hover, pressed, focus, and disabled treatments. A selected navigation item may need a subtle background and a stronger foreground. These are behavioral requirements, not an invitation to generate a ten-step rainbow.

Every derived value should retain a relationship to its source. Record whether it was mixed with the canvas, darkened for contrast, or replaced because the original could not satisfy the role. This makes the decision reproducible for designers, developers, and AI agents.

4. Test the pairs people will actually see

A color is neither accessible nor inaccessible on its own. Contrast belongs to a specific foreground and background pair. “Our green is accessible” is incomplete; “our white button label on the primary green measures 6.2:1” is a testable statement.

Evaluate body text on the canvas, button labels on every button state, links on their real surfaces, placeholders inside inputs, focus indicators against adjacent colors, and status text inside banners. Also remember that passing contrast does not guarantee that two colors communicate meaning clearly, particularly for people with color-vision differences.

5. Name tokens by purpose

A primitive such as --rust-700 describes appearance. A semantic token such as --color-action-primary communicates responsibility. Components and AI coding agents should consume semantic tokens because those names survive a redesign.

Keep primitives underneath when they help document the source values, but expose roles at the implementation boundary. This gives teams the freedom to change a value once without searching through every component.

:root {
  --color-canvas: #f3efe7;
  --color-surface: #f0e8e0;
  --color-text: #171512;
  --color-text-muted: #6f6c67;
  --color-primary: #9d3f2d;
  --color-on-primary: #ffffff;
  --color-primary-hover: #843526;
  --color-primary-subtle: #e5d3c9;
  --color-border: #8c8983;
  --color-primary-border: #9d3f2d;
  --color-focus-ring: #b66f62;
}

A worked example

Suppose the starting brand color is #9D3F2D, a warm rust. We assign it to the primary action. A warm paper canvas, #F3EFE7, supports the personality without forcing the entire interface to become orange. Near-black #171512 becomes the main reading color.

White on the primary rust measures 6.59:1, so it can support normal-size button text. The compiler derives #843526 for hover, #E5D3C9 for a subtle primary surface, and #B66F62 for focus. Every intended pair passes its declared WCAG 2.2 threshold, and every transformation remains visible in the output.

A practical first-system checklist

1. The brand color has one clearly stated primary role.
2. Canvas and reading colors were chosen for content, not decoration.
3. Every generated shade maps to an actual component or state.
4. Contrast claims identify the exact foreground and background pair.
5. Errors and statuses do not rely on color alone.
6. Components consume semantic names rather than raw values.
7. Transformations and source colors remain documented.

A small explainable system is stronger than a large speculative palette.

Start with the roles you can defend and test. Add another only when a real interface requirement appears. The goal is not to produce more color—it is to make fewer, better decisions.