Singularity Theme — Why did we change the colors of our console

In this article, we’re going to present the full process we went through when we decided to change our main product color palette to make it more accessible and usable. We will list the reasons that got us into this process, the defined goals, the preparations both on the front-end side and the user interface side, and the process itself. We hope both UI designers and FE developers can benefit from our journey of creating a new color palette in an already running and living product in the best possible way, without disrupting other processes in the organization.

Our main product is the Management Console: a SaaS product made for security experts to prevent, detect, and manage threats — mainly ones related to endpoints. As a startup, SentinelOne grew amazingly fast due to impressive and innovative AI technologies and proven detection capabilities. The need to grow and deliver fast created a situation whereby some visual inconsistencies both on the UI side and the code side were presented. The inconsistent styling raised questions on the client-side about things like our accessibility level, readability, and the extent to which it impacted the user trying to learn and use the product. We decided to confront these different problems by setting up a few goals:

  1. Get as close as we can to the WCAG 2.0 AA accessibility level
  2. Make the data easier to read and understand
  3. Enforce an easier and more flexible usage of colors and components

At SentinelOne, we want everyone to be able to use our products and services easily and productively. When some of our clients raised accessibility issues, we were keen to see how we could improve their experience. To make the system more accessible, we understood we needed to change our color palette, mainly on the typography side. After we mapped the problematic colors and pages, we compared them to the WCAG 2.0 regulations for accessibility on the web and made sure we met the regulations and fulfilled our customers’ needs.

When going through our system, we noticed some inconsistency issues. When someone tries to learn how to use a new user interface, their brain tries to find patterns: “Which color signifies a button?”, “Is this dropdown item selected?”, “Does this red color signify a warning?”

Consistent design helps the user learn and create rules for using the system. It should facilitate fast learning and feel intuitive to understand. Importantly, a consistent experience increases productivity, allowing users to successfully complete tasks without interruption due to confusion and mistakes.

To accomplish those goals we started by assigning two dedicated people to the mission — one on the FE side (Ofir Fridman) and the other on the UX side (Amir Binenfeld).

Amir and his team created a design system, starting by creating a color palette and making sure every color in the palette used for text is accessible. Part of the color palette creation consisted of a naming convention that is memorable and flexible. The palette is divided into 5 main parts — “Primary”, “Secondary”, “Neutrals”, “Semantic” and “Data Visualization” — and built out of the main color, and tints and shadows scales.

The scale is named with the first letter of the specific part (like P for “Primary”) and by a number stating the brightness of the color. Our primary color was P40 and we started with hops of 10 (P30, P40, P50, etc) to signify the color brightness. The hops gave us the flexibility to add mid colors for our need, like P2, which was added during the process when we understood we needed another extremely bright color

To manage the replacement of the colors we needed a mid-stage before the full replacement. The process raised some challenges on the front-end side:

  1. Removing the old declarative CSS color variables
  2. Creating new declarative CSS color variables
  3. Replacing old CSS color variables used in the code
  4. Keeping the new color branch updated with the master

Our first step was to remove the old declarative CSS color variables and use the new ones.
Once we were done, a script was created that runs over our SCSS files and replaces our old color variables with the new ones. The script made it easy to update the color branch and make sure that new features coming from the master are aligned with our new color variables.

After creating and setting the new color variables based on the old ones, we were ready to jump headfirst into the consistency challenge. We went through every screen of the system and searched for inconsistencies. Ofir came up with a smart trick to find colors that aren’t configured with variables at all. He replaced all our CSS variables with one RGBA. In this case, he set it to “red” with an alpha channel of 0.1.

For example:

:root{ - s1-A-10-color: rgba(255, 0, 0, 0.1); - s1-A-20-color: rgba(255, 0, 0, 0.1);}

Then, he opened our console in order to find where we are not using the CSS variable.
Here is an example of how it looked.

Now we could easily see that the “Threat Landscape” text doesn’t use the CSS variable since if it was, it would be glowing red.

When we found colors different from the new variables, we selected the right color and configured it. Now that every element on the system is defined with color variables, we have control over the system’s color palette in a central place. This gives us the flexibility of changing colors all over the system with no problem and creating different themes like “Dark Mode” in a matter of minutes.

To keep our system within the guidelines we’ve set, Ofir also installed a linter called stylelint which enables us to enforce rules like “no hexa colors” and “no RGBA” as you can see here:

"color-no-hex": true,"color-named": "never""function-disallowed-list": ["/^rgb/", "/^hsl/"],

The process made us take some hard decisions related to color usage, but it was satisfying to finally see a clean and readable system that will serve our clients’ needs.

Before — the table had many colors, it was harder to read and scan, and also inaccessible
After — accessible colors, easy to scan, easy to understand what’s clickable and what’s not.

Before — a lot of unnecessary shadowing, inaccessible text colors

After — accessible colors, bigger differentiation between hierarchies

Before — a bit confusing and inaccessible
After — accessible and using light colors. consistent with the system’s design

This article was written by Amir binenfeld and Ofir Fridman.

They are hiring- come join their team! See SentinelOne open positions at:

Originally published at on February 23, 2021.

Product Designer at Sentinel One. I’ve worked with Startups in various fields like Gaming, Cyber Security, and Medical tech.

Product Designer at Sentinel One. I’ve worked with Startups in various fields like Gaming, Cyber Security, and Medical tech.