Color palettes are at the core of any design. As designers, we can spend hours painstakingly doing color studies, eyedropping hex values, and poking saturation levels until our colors are just right. And not only that but we do it for every color in our app—buttons, text, hover states, links, alerts, icons, charts, and of course, the seven shades of slate for good measure.
All of that color picking means there’s a lot of CSS floating around the web defining color. Luckily for us, CSS preprocessors came onto the scene years ago and solved all those problems by introducing variables. Designers were saved. Or rather, developers were saved from that inevitable moment when we change our minds about that specific shade of slate.
But that didn’t actually solve the problem of making colors easier to manage.
In a recent project where we were paying back some technical debt, we crawled through a client’s legacy and current codebases and found an astounding 926 hex values. Not only that, but there were over 60 different color variables (with really clever names like Sunshine and Lemon). Along the way, variables compounded–they became more complex and numerous. Developers didn’t know if close hex values were a mistake or not so new variables were created in response. When I reviewed a layout, I noticed not one, but four different variables defined for aqua in use at once on the same page.
The problem of compounded confusing CSS colors isn’t really specific to that client, though. I see it all the time in the place where the problem actually starts: the initial specced color palette of a design system.
After some time I started thinking, “What if instead of creating a palette of color values, we created a palette of color relationships that were defined by Sass?” This approach would rely on far fewer unique values and decrease the amount of overhead of the design system. It would also make the colors far more flexible and easy to swap globally should a change occur (and you know it will). I used our next client project to test it out in real life.
The concept starts with core colors that fall into two categories: layout and feedback. Layout colors are for things that you use to build a page—text, links, headers, containers, buttons. Feedback colors are for UI with semantic meaning—save, delete, success, warnings. Sidenote: a brand color that can do both is a double-whammy in this case.
Our palette for this project has five core colors: a dark, a light, a primary and secondary brand color, and white.
From these colors we can use Sass variables to build any number of variations, but the important part is to let the preprocessor do its job. These powerful tools can manipulate colors in all the ways you would yourself—if you let them.
Hovers aren’t unique hex values, they’re the original colors darkened 10%. Shades of grey are tints of the dark value, output for use as text, headers, and icons. Our light tone is processed to create light neutrals that still retain their blue tints—all without specifying another hex value or defining another variable.
By focusing on how colors should relate and using Sass to map them, we can create a simple palette of 12 colors for use across our UI with 5 core hex values. To round out the feedback colors, we add an orange and red that fit the family for a total of 16 colors controlled by 7 hex values. And this is just the tip of the iceberg. The beauty is that if we need a new shade of light grey we process the light value differently—creating another new color from our core palette. Down the road, swapping out a core color will generate all of its relationships accordingly, making changes to the branding or possible white-labeling a breeze.
If you’re a designer and think that Sass is a great tool for devs, you’re right. It is. But it’s also a powerful tool in the design tool belt, and one that will keep your color systems lightweight, flexible, and easy to manage for years to come. Next time you need to create one, why not let Sass do most of the work?