Project 06
COLORS CASE STUDY
Color theory is a science and art unto itself, which some build entire careers on, as color consultants or sometimes brand consultants. Knowing the effects color has on a majority of people is an incredibly valuable expertise that designers can master and offer to their clients.
It goes without question that color helps inform how we perceive the world. Color evokes certain emotions, guides actions, and helps inform expectations.
In web interfaces, we can use color to create and reinforce patterns. Through reusable patterns, we know that blue text often means a clickable link, and red often means something went wrong. Back in 2016, Google was experimenting with new link colors which confused many users when it switched to black. The tech giant also experimented with a variety (over 40 in fact) of shades of blue in order to test clickability. When used correctly, color can help emphasize and guide actions within our products; however, it can also lead to complex interfaces if it is not used with consideration.
After performing an audit of our product, it became clear that there were few guiding principles as to how we used color to create patterns and emphasize actions. As teams grow and scale without a system in place, it becomes more difficult to build consistently. Often times, new colors get introduced for one-off cases, leading to an insurmountable amount of tech and design debt.
I wanted to start from the ground up creating a system to scale design and build a system with ample documentation and training so that we could build faster without breaking things.
We also want to be empathetic for the wide variety of how people see or don’t see color.
Our product should be accessible to everyone. Color should help reinforce patterns but not define them.
Getting Started
We kicked off our design system process with allocating time during our sprints to work on unifying, testing, and implementing a new color palette. Since colors affect all parts of the system, we wanted to focus on thinking through this piece first.
We had an initial color palette in place that defined our brand but it was limited to 12 defined colors. It contained 4 primary blues, 4 shades of gray, and 4 accent colors.
I started looking into our code by running our site through CSSstats and matched them with our current color palette. I discovered that what we had in our initial style guide didn’t match what we saw in production.
Although we only had 12 colors defined in our style guide, CSSstats showed that we had 95 unique text colors and 103 unique background colors.
We began mapping all the colors we saw in production to what we had in our style guide. This allowed us to see variations in our colors and see how they mapped with our current style guide. We also searched our codebase to see how each color was being used within our product. This allowed us to make more informed decisions later on.
Creating a new palette
Universal design and accessibility wasn’t a huge focus for Crismon; however, it’s something we want to design for in the new system.
We went through several rounds of reviews and testing to find the right number of colors and the right shades.
In the end, I took our base colors and expanded it into 10 stops. Each base color had 5 levels of tints and 4 levels of shades applied. It was a simple method that allowed us to hit the ground running. There are more systematic approaches to selecting colors based off of algorithms, but we wanted to move quickly and be flexible with our approach.
I tested each color for contrast and accessibility using Stark, a color-blind simulator and contrast checker for Sketch.
Naming convention
When performing the initial audit of how use used colors at Crimson, I discovered an inconsistent naming convention. We had colors defined by their actual colors such as , navyblue, lightblue, and bluegray. We also had them defined by their use case such as bordergray, alertred, warningred, warning_pink (yes we had several warning colors). There was absolutely no structure and it was clear that colors were being created for specific use cases. This lack of structure led to new variables being created for one-time use cases.
