Reworking a Color System for Flexibility and Growth
When your color system gets ugly, how do you make it pretty again, and keep it that way?
How it Got Ugly
When thinking about colors in the world of design systems, we think of neat, pretty columns of colors with hue, saturation, and brightness variants. Everything falls into these columns, and lives in a nice harmonious balance to create consistent applications across an entire ecosystem.
The Astro Space UX Design System (Astro UXDS) started this way, with four main columns of blue hues to use as a base for building the UI.
Of course, a UI cannot simply be shades of blue. There are numerous data visualizations, graphs, and tables that need to convey information quickly and clearly. Astro UXDS is used in the Department of Defense and military applications, requiring alerts and warnings of various levels of severity that must be visualized. In the case of the military applications, there are classification levels and standards to adhere to. There are also numerous defense contractors and subcontractors in siloed environments, each building from different design systems and bringing in colors that work for their applications. As an open source design system, one of Astro’s primary responsibilities is to pull together common design patterns and colors. Over time, we found that our base palettes were too inflexible, and we needed more subtle variations to represent effects like opacity. Finally, Astro UXDS has both dark and light color themes. That alone doubled the amount of complexity in thinking about color.
To accommodate all of this, new colors were added over time. Not all fit into our nice, neat system. Some status and classification colors overlapped and needed variants for borders and icon states. Many colors in our original palette were never used.
The Astro color system was becoming more and more convoluted, and increasingly difficult to maintain and explain. What color was supposed to be used where? Did certain colors have meaning? Were certain colors off limits? Would this be a color system designers and developers would want to use?
In our original four columns of blue colors, 14 of the 36 blue colors (39%) were never used. There were different classification and status colors that were developed independently and therefore didn’t fit cohesively into the system. There were 14 outlying colors that didn’t fit into any grouping, some so close to other colors that there was almost no discernible visible differentiation.
Some colors were required for compliance by various organizations and standards. Some colors had specific meaning and should not be used for other purposes. Some had no use at all.
We needed a way to consolidate and organize these colors.
Making it Pretty
In our review of Astro UXDS, it became apparent that we could clean up the system. Colors that were required or commonly used were kept and served as the foundation for our color system. Unused colors were eliminated. To determine which colors were the most efficient for our system, similar and redundant colors were analyzed and consolidated by running tests on sample applications in multiple modes.
We also considered accessibility via color contrast in choosing our new colors, and consider it vitally important to Astro UXDS. We are building a color-blind accessible system, so we put a lot of consideration into what colors will be legible on top of other colors. Throughout our process, we engaged in a significant effort to test color contrast for improved legibility of text and other content on background colors. This forced us to make adjustments in order to meet WCAG 2.1 Accessibility Guidance. While this work is always ongoing, we now have a solid base to work from to improve accessibility throughout applications using the Astro design system.
Once we had a set of colors, we started putting them into logical palettes based on hue and saturation. When we saw them together, we quickly saw outliers that did not fit into the system. We adjusted and tested colors based on use cases, and ultimately built a cohesive color system.
We were back to having a pretty design system. Now came the final question, how could we keep this system from devolving into chaos in the future? We wanted to lay a strong foundation for Astro UXDS, and felt we had a strong start. However, we also knew that color and design patterns are always shifting, so we needed to have a system with flexibility built into it.
Keeping it Pretty: Design Tokens
Astro UXDS needs to be a modern design system that works equally well for designers and developers, so that applications can be built consistently across a multitude of organizations, companies, and clients. We decided to move to a design token framework that would define all colors, variables, and usage patterns for applications, and deliver them using a consistent naming pattern. If a color token was used in Figma to design a UI component, that same token would be used by developers to build that component for the web, mobile, and large screen versions of that application. As Astro UXDS supports a wide range of product teams using a diverse array of tools, this is critically important in creating consistent experiences across applications. By implementing design tokens across various platforms — such as Google’s Material design system, Tailwind CSS, and AG Grid — development teams could use Astro UXDS without having to switch to a different system.
When thinking about our new system and how to organize it, design tokens really helped shape our vision. We took our updated color groups, and created manageable palettes of reference color tokens. These reference tokens set the base of available colors to work from. The palettes were also flexible, so that if we discovered another use case, we could add colors within the palettes. These palettes included colors for both our dark and light themes that we could consistently use across both themes.
We then developed a set of system color tokens. These pulled from the available reference color tokens to set high-level guidelines for using colors when developing applications.
Finally, we started building a set of component color tokens. These are precise tokens that define all of the colors used to build individual components, such as backgrounds, borders, text, icons, hover states, and any other colors needed. Generally they pull from the system tokens, though at times they pull directly from the reference tokens if their values are not used system-wide. There can be many of these, and we have not covered all of them. But over time, the tokens will grow and become more refined.
With this foundation, if we need a new color palette or theme we can fold it in without affecting what is currently there. Or if a color change is needed to a component or multiple components, that color can quickly cascade throughout the application without leaving old instances behind. This flexibility gives us the strength to move forward quickly and approach new design challenges with a solid foundation.
There have been many discussions and explorations on what we want to do and where we want to go, and there will be more in the future. But we hope to have started building a color system that both designers and developers will understand, want to use, and expand upon in the future.
