How we achieved an automated color palette that designers and developers love.
Guiding us with the less is more principle.
At Homeday we take consistency and efficiency as guiding principles, this meant that, when we started working on our design system, we knew designers and developers needed to join forces and collaborate in order to achieve a system that would be easy and effective for both.
Therefore we knew we needed to start with the foundation, colors, the ones that rule the way, not just in design but that will make our brand recognizable, meaningful, and valuable.
To set a strong base, we first started by reducing the number of colors we were using, and leave only the ones that speak our brand principles. So together with marketing and developers, we decided to choose the main colors that define Homeday’s values.
From this selection, we decided, to first define our primary, secondary and functional colors, and then expand our color range by creating shades out of them. This also ensures sufficient color contrast, between elements used in our products and marketing material, to comply with the AA standard contrast ratios, which helps people with any type of vision impediment to see and use our products with ease.
The challenge of creating shades
We approached the challenge by considering the following:
- How can we make the shades out of our base colors and any color we choose, consistently?
- How can we make the shades “automated” from the design perspective, to then translate them into code?
- How can we automate the shade generation without having to save each one of them in the codebase?
Our approach
First, in the design team, we tried different ideas, from changing the opacity, which unfortunately made the shades dull, to adding and subtracting values from different formats, RGB, HSB, until we found that if we took steps from the Luminosity out of the HSL values, this would give us richer shades and a decent range of colors we could use across all our products and marketing material.
With that in mind, we created a rule of +-10 steps for lighter and darker shades to adjust accordingly from our base color.
Like you can see in this example, the Luminosity (L)value changes by a factor of ten while the other values stay exactly the same.
The only downside of this rule is that the number of shades we can have from every base color is directly dependant on the luminosity of it. Therefore from colors that have less luminosity, we can have a bigger range of shades, opposite to a more luminous color.
Like in this example, for the blue, the range of generated shades is way smaller due to its high luminosity, compared to the gray, which allows for more shades to be made until getting into almost pure white.
For us, this wasn't so much a point against, instead it actually gave us the opportunity to create something more “automated” in design, that everyone can follow through and keep consistency every step of the way.
So now it doesn't matter if we change or add other colors, or if we decide to change them completely, we can stick to this rule to make a successful palette without much effort.
Shades, same as colors, need names, so we needed to define some naming conventions
Now that we have all our shades, we needed to define naming conventions that will allow us to identify them, but most importantly, to have common terminology for designers and developers, to refer to, allowing us to speak the same language, and allow developers to create abstractions in code. For us, this is how it looks:
We first abbreviate the name of our base colors to give a hint to which color the shade belongs to.
Then to represent the subtraction or addition of the luminosity in every shade, we took 100 as the reference for the base color, which means, lighter shades were represented from 90 — downwards, and darker shades were counted from 110 upwards.
Like in this example, our primary color Cello Blue will be CB. plus the number of the shade (from 100 up or down)
Implementing the new shades into code
Thanks to CSS preprocessors, implementing this new shade approach, was pretty straightforward.
As you can see, in the snippets below, we are using SASS (with SCSS syntax) to achieve this, but I’m pretty sure your favorite CSS preprocessor supports variables, lets you create your own functions, and has some basic color functions.
The same way designers did, we started by defining our color palette:
We realized that using these variables directly in the code might not be a good idea, if we decided to change one color, we would have to replace it in the whole code base, which increases the amount of effort, especially if you have multiple projects, and let’s not talk about in case of a full rebranding.
That’s why we added a layer of abstraction:
We agreed to only use the abstraction variables in our code. This way, changing a color means changing two lines instead of a global find-and-replace in multiple projects.
Now that we have our colors defined, here is the simple function we use to generate the shades:
change-color is a function provided by SASS’s color module.
As explained in the naming conventions section, our reference shade is 100. One caveat is that our shades are based on the rounded lightness value of the base colors, for example, cello blue’s lightness is 21.8%, but to generate the shades we rounded up to 22% instead.
So the code above can be even simplified by using the adjust-color or even lighten and darken function if you base your shades on the exact lightness value of your main colors.
Now, using a shade (DB110 in this example) is as simple as:
The full code can be found in the colors.scss file of our Vue component library.
Mapping all the colors
Once we finished with all the colors, we decided the best way to now migrate the new shades was to map out the “old” colors with the new shades, this way it was easy for designers and developers to keep the naming conventions and just overwrite them with the new values
This is not the end but the beginning of something bigger …
In Conclusion
This was our first approach at automating color shades, even though it was a challenge to get the final version, it definitely made a difference in how we handle colors now
I had a lot of fun doing this project together with Ilyas Amezouar and the help of the whole Design and Front-end teams 👏🏻👏🏻👏🏻
If you like to try this in your next projects, feel free to use the examples to guide you on generating your own palettes, and let us know the result
Last but not least, Homeday is hiring, so if you want to take part in building useful and fun products while collaborating with a cool team of designers and engineers, click on the link and apply, we would love to hear from you!
