Colors at scale

Let’s start by saying that I was reading Pedro Moreira’s article about Gitlab’s color palette and I felt inspired to write my own, as I’ve faced similar challenges. Let’s also make clear that the way we did it may not work in your reality.

Working on SoftExpert’s Design System has been a great experience in terms of understanding more of our technical aspects, thinking at scale and going back to the basics of design.

We have 35 management products and more than 20 years of history, so it has been a great challenge to put all these products on the same page.

Right at the beginning, the squad focused on the Design System started to question about some aspects of our color palette. And these were the main problems:

• We had a lot of colors;
• No instructions about when to use each color;
• A low understanding of colors in a digital product context;
• There wasn’t enough contrast.

So let’s dig a little deeper.

1 — About having too many colors

Yes, we know. You made an awesome layout. Then your friend did the same. And by now I’m pretty sure there’s a developer looking at the screen and thinking:

Nope. This color isn’t working, I can’t even read this label.

And he will try a better color. And he’s not thaaat wrong. But in the long term these are the results:

We had up to 162 colors in our CSS files. It was impossible to know which color to use in our prototypes, we had a lot of similar colors and most of the combinations had bad contrast. How might we make any sense of this? The first thing we did is related to the next topic:

2 — Instructions about when to use each color

Considering the scenario above, we started to group colors based primarily on the final use:

• Backgrounds;
• Texts;
• Borders;
• Shadows;
• and Overlays.

And later we’ve added a documentation about the message sent by the color:

This allowed us to discard a lot of similar colors and establish some guidelines for them. It was a good start, so let’s keep it here for a moment and move to the next topic.

3— A better understanding of colors in a digital product context;

When we think about colors at scale, we’re talking about ease of use (for both designers and devs), and modularity. Right at the beginning we reduced the number of colors, but we also found some other problems:

• How can we deal with the shades of gray?
• Solid colors? Opacity? When? Which?
• How can we make things modular?

The thing is: you can’t always have solid colors, and you also can’t always have opacity colors, especially when we talk about white and shades of gray.

Let’s take a look at this example, where I use “the same color” in HEX and RGBA values for text:

If you use a shade of gray as a solid color for text, it will not have flexibility in most contexts, working mostly on a white background or something similar. In addition, you will be required to have a hexadecimal value for each shade of gray.

In counterpart, when you use the same color but working with opacity, it will be more flexible on different backgrounds, and you will have only one color: Black. The difference is you’ll have design tokens for each different opacity.

So we mapped that. And we defined that some scenarios require solid colors, and some other scenarios require working with opacity.

We’re using now solid colors for:

• Backgrounds;
• Borders;
• and some of the colorful text.

And opacity for:

• Text;
• Shadows;
• and overlays.

This allowed us to reduce our palette from 161 colors to 21 colors.

So what about all that modularity and shades of gray talk?

Tokens everywhere!

In cases where opacity is needed, we have specific tokens for it. And if we need an equivalent solid color, we also have a token.

By doing this, we have way fewer colors, ease of maintenance and ease of use for everybody. The image below is the deliverable: our current colors documentation, separated by use.

Last but not least:

4 — Better Contrast

For all background X text combinations, we made tests and adjustments on our colors and components using the Contrast Ratio Tool to make sure we have compliance with WCAG recommendations.

This allowed us to document the combinations to avoid confusion.

Most of the times you will work with color adjustments, making colors a little darker or lighter here and there, but sometimes it’s necessary to use a completely different color on a component to make it readable, but the important thing is to ensure accessibility for the users.

Closing notes

• This was the first step in dealing with colors in a more mature way at SoftExpert and it’s working very well since it was released!
• We don’t have a very complex color reality yet, which led the study to an exercise of reducing the number of colors, working on guidelines, modularity and accessibility, without getting too deep into color theory;
• It was a task done in two weeks with the support of our DesignOps Lead João Victor and Letícia Peixer, which is an UX designer from the Design System team;
• We’ll have to set an additional palette for data visualization soon, so… maybe that’s a subject for part 2…(?)

Did you have any similar challenges? solved it in any different way? Is there something in here that doesn’t make sense?

Let me know in the comments so we can all evolve together!

I could not finish this article without thanking João Victor and leticiapeixer which has been real warriors at stablishing our DesignOps culture. I’d also like to thank SoftExpert Design Team for the support. ❤