Last year, my team at SparkPost set out to craft a new color palette for our design system, Matchbox.

With a new focus on accessibility, and a rapidly growing app, it was clear our palette needed a refresh.

SparkPost’s color palette over the years

Colors Are hard

Historically, we’ve always favored a limited palette with few color options. We believe that more choices encourage misuse and can lead to inconsistency in an interface.

However, it became apparent that our design system didn’t have what we needed to support a growing component library or our array of data visualizations, while meeting accessibility standards. We realized how demanding designing browser-based interfaces can be, where the smallest difference in a color can cause an interface to fail accessibility testing. Our palettes needed a redo–and here’s how we did it.

A dropdown menu and date picker illustrating the amount of grays used in common UI elements


Neutrals are important because they provide visual cues and establish structure and hierarchy to interfaces. These colors will be used more than any other color scale, from typography to drawing boundaries, so it was important for us to get it right.

We started with a gray scale of fourteen grays, with the intention of testing it and cutting it down. Using the HSB (hue-saturation-brightness) model, we created grays ranging from a brightness of 24 to 96, with even intervals in between. We chose to start our scale at 24, as opposed to a darker color, because our front end interfaces are predominantly bright and we needed lighter lights more than we needed darker darks.

We removed these muddy midtones

After evaluating this scale with common UI elements and typography, we recognized the need to eliminate muddy midtones, which provide little to no contrast with other colors in the scale.


Implementing fewer midtones lowers the risk of a designer or developer using a low-contrast color combination and maximizes the number of available accessible pairings.

Our grayscale colors tested against each other for WCAG compliance

The chart above shows a color contrast ratios mapping of our grays against each other, highlighting the midtones we removed. We wanted to make sure that the neutrals we chose had a contrast ratio of at least 4.5:1 to our dark or light backgrounds in order to meet WCAG AAA requirements.


When we were finally happy with our neutral grays, we applied the same brightness scale to our other hues. This ensures that, like our grayscale, our hues would have accessible color pairings within their spectrums. This involved countless hours of tweaking eighty different shades of colors, but the end result was well worth the effort.

We used a white layer with the color blending mode to transform colors to a grayscale.

Through expanded scales of tints and shades, our designers and developers have the flexibility to consistently build complex interfaces. No more one-off or conflicting custom colors. Anyone who uses our design system has the palette needed to easily create color combinations of their own that are accessible.


With a full color palette in place, we then evaluated whether or not it would work for our users. We continued to tweak our colors through rounds of UI prototyping, and color-blind user interviews. Tools such as Stark and Viz Palette were incredibly helpful in this regard.

After further refinement, we were confident we created a reliable color system that we could build UIs with.

Example of SparkPost’s new colors in use

Closing Notes

We’re really proud of all the work we’ve done to build a flexible and accessible design system color palette. The color foundations we’ve established not only improve the experience of all SparkPost users by providing accessible UIs, but help us iterate faster as designers and developers by using a consistent and flexible color system.

If you want to learn more about our design system, visit our design system’s website.

Additional Resources

~ Jon