Evolving a Stale Style Guide into a Scalable Color System in Figma

At B. Design Collective, we recently took a step back to evaluate something many teams quietly struggle with: a color style guide that no longer scales with the product.

What started as a straightforward palette—primary, secondary, and a few supporting colors—had slowly become rigid, inconsistent, and difficult to maintain. Variants were created ad hoc, accessibility considerations weren’t always predictable, and applying colors across components required too much manual decision-making.

So we decided to do what every good design system team eventually must: eat our own dog food.

Static branding colors

The Problem with “Static” Color Systems

Our original palette wasn’t wrong—it just wasn’t built for scale.

Like many early-stage systems, it focused on:

• A small set of brand colors

• Limited shade variations

• Direct application of hex values in components

But as our product matured, so did our needs:

• More nuanced UI states (hover, active, disabled)

• Consistent feedback patterns (success, warning, error, info)

• Dark mode and theming considerations

• Accessibility and contrast requirements

The result? Designers and developers were making too many judgment calls in the moment.

That’s when we realized: We didn’t just need better colors—we needed a better system.

Shifting to a Token-Based Mindset

Instead of thinking in terms of “colors,” we reframed the problem as color tokens and roles.

This meant moving from:

“Use this green” → “Use color.background.success”

From:

“This looks like a hover state” → “This is color.action.primary.hover”

This shift allowed us to:

• Decouple design decisions from raw values

• Create consistency across components

• Enable scalability across themes and modes

Building Beyond Brand Colors

One of the most important mindset shifts in evolving our color system was recognizing that brand color selection is only the starting point—not the system itself.

In many traditional style guides, color is treated as a static layer of visual identity: a primary green, a secondary accent, maybe a highlight color, and a handful of neutrals. While this works for marketing surfaces or lightweight UI, it quickly breaks down in complex product environments where color must do work—communicating state, guiding interaction, and reinforcing meaning.

To scale effectively, we had to move from thinking about color as expression to thinking about it as infrastructure.

A scalable color system isn’t defined by how many colors you have—it’s defined by how clearly those colors are organized into functional roles that can be reused, adapted, and extended across contexts.

1. Core Brand Palette

We began by grounding the system in our core brand identity, but with a more systematic approach to structure and flexibility.

Rather than a flat set of approved colors, we built full tonal ramps for each core hue:

• Green (primary identity)

• Coral (secondary accent)

• Gold (tertiary highlight)

• Neutral greys and foundational base tones

  
  

Each palette was expanded into a consistent scale (light → dark), creating a predictable progression of values that could be reliably used across different UI needs.

This allowed us to:

• Support a wide range of use cases (backgrounds, text, borders, overlays)

• Maintain visual harmony across components

• Avoid one-off color decisions that lead to inconsistency over time

More importantly, these ramps became the raw material for the system—not the final output. Designers no longer “picked a green”—they selected from a structured range based on context and purpose.

2. Feedback Colors

If brand colors define identity, feedback colors define communication.

This is where many systems fall short—treating success, warning, error, and informational states as afterthoughts or loosely applied overlays. In reality, these colors carry critical meaning and must be handled with precision and consistency.

We established dedicated token sets for:

• Success

• Warning

• Danger

• Info

Each category wasn’t just a single color, but a fully defined system of roles, including:

• Background layers (subtle → strong emphasis)

• Foreground elements (text, icons)

• Borders and outlines

This structure ensured that every feedback state could be applied consistently across:

• Alerts and banners

• Form validation

• Notifications

• Inline messaging

We also prioritized:

• Accessible contrast pairings, ensuring readability across all states

• Semantic clarity, so that a “success” always feels like success—regardless of where it appears

These colors are not decorative accents. They are signals—and like any good signal system, they must be instantly recognizable, consistent, and reliable.

3. Interaction & State Layers

One of the most overlooked aspects of color systems is how colors behave over time—specifically, how they respond to user interaction.

Color is not static. It shifts, reacts, and reinforces feedback in response to user input.

To address this, we defined a comprehensive set of interaction states for all color-driven elements:

• Default

• Hover

• Active

• Focus

• Disabled

Rather than relying on ad hoc adjustments (like randomly darkening a color or applying opacity), we created predefined state tokens mapped to each color role.

This allowed us to:

• Standardize how interactions feel across the entire product

• Eliminate inconsistency in hover/active treatments

• Reduce guesswork during both design and development

Designing for Modes (Not Just Colors)

Another major evolution in our approach was expanding beyond a single visual context.

Modern products don’t live in just one mode—they must adapt to:

• Light mode

• Dark mode

• Potential future themes or brand extensions

To support this, we separated the system into two distinct layers:

1. Base color values (the actual hex/RGB scales)

2. Semantic usage tokens (how those colors are applied)

This abstraction is what makes the system flexible.

For example:

• color.background.primary is not tied to a single hex value

• In light mode, it may map to a light neutral

• In dark mode, it maps to a deep surface tone

The component using that token doesn’t change—only the underlying value does.

This approach allows us to:

• Switch themes without redesigning components

• Maintain consistency across modes

• Future-proof the system as new needs emerge

Ultimately, designing for modes forced us to think less about what a color is, and more about what a color does.

And that distinction is what transforms a palette into a truly scalable system.

Here's what we learned...

Every color must serve a purpose, whether it’s communicating meaning, guiding interaction, or reinforcing hierarchy. True scalability comes from abstraction, which is why tokens will always be more powerful than static hex values. Additionally, interaction states and feedback patterns must be treated as first-class citizens within the system—designed with intention from the start, not layered in as an afterthought. Finally, we recognized that design systems are never truly “finished.” A static style guide quickly becomes outdated, while a living system evolves alongside the product it supports.