top of page
Search

Transforming Our Color System for Scalability

Mar 21
4 min read

Updated: Jun 27

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.


Color palette chart with columns labeled Green, Pink, Yellow, Black, Red, Grey, and Feedback types, showing various shades and corresponding hex codes.

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.


In conclusion, our journey to refine our color system has taught us invaluable lessons. The process of creating a scalable color system is not just about colors; it’s about building a framework that supports our design and development efforts. Embracing this mindset allows us to create products that are not only visually appealing but also functional and user-friendly.


By focusing on the purpose of each color and its role within the system, we can ensure that our design choices resonate with users and enhance their experience. This is the essence of a successful design system, and we are committed to continually evolving and improving it.


---wix---

 
 
 

Comments


bottom of page