Introduction

Fastly is rebuilding its marketing website and marketing design system (Consistently). Big Human, an external agency hired by Fastly, handed off a raw set of branded colors that were used in a “color block” pattern within their web template mockups. I used these mockups to develop a better color system for our production process.

We accomplished some of the following after making a new, better color system:

1. We are now inclusive of a wide spectrum of vision needs among website visitors by complying with WCAG 2.2 and 3.0 standards.
2. We can now automate color themes through a flexible design token framework.
3. We are able to create a consistent web experience between different domains that are maintained by different teams.

Research: inclusive colors

I took the initiative to research more inclusive color system approaches before letting the developers build out this new system from scratch. As a result, I challenged our internal teams to rely on the LCH color space and to measure color contrast by referencing WCAG 2.2 and the upcoming WCAG 3.0 (APCA) standards.

I created a new color system that organized colors by relative luminosity—this made it easier for designers to propose accessible color usage within their designs. This new color system was also adopted as the Core Color token structure that the Engineering team would rely on to apply colors on the website.

Test: accessible color choices

This tangible system made it easy to determine what shade of specific colors would be appropriate for functional use cases like autocomplete highlighting features. Since a highlight is neither “essential content” (needs to meet a minimum of 4.5:1) nor a “visual graphic” (needs to meet a minimum of 3:1) the highlight color just needs to be “visible”. WCAG 2.2 doesn’t have great guidance for this definition, but WCAG 3.0’s APCA method does—it identifies a contrast value threshold for what is considered “invisible” (values less than Lc 15) and “visible” (values greater than Lc15). 

Option 1 uses the hex code #E7FF7A (Electric Lime Green) which has a WCAG 2.2 contrast value of 1.11:1 but a WCAG 3.0 contrast value less than Lc 15 (invisible). Colorblind audiences with Tritanopia will miss out on this color highlight because of the lack of luminosity and hue. 

Option 2 showcases the same experience with a more accessible color choice for this type of feedback, #99DDFF. This color has a WCAG 2.2 contrast value of 1.49:1, but a WCAG 3.0 contrast value of Lc 22.76—confidently visible to most types of sightedness. The choice of switching this cue from green to blue will be explained further in this next section.

Color roles for web themes

Ensuring the consistent application of these colors proved to be an immediate challenge—it was hard for everyone to continuously recall specific color roles. The team needed to understand the relationship between several key roles that I observed from the new color block pattern: backgrounds, foregrounds, content texts, and interaction cues.

‍Background colors

Background colors were the most straight forward role. The team understood this role to be full bleed washes of large color—we identified four background colors that appeared within the color block pattern.

Foreground colors

Foreground colors were considered to be spots of color that were placed on top of background colors. They could be as small as icon backgrounds, or could be as big as a large card containing high-priority content.

Interaction cue colors

Interaction cue colors were eye-catching colors that were intended to grab visitors’ attention. We decided to assign two colors for this role, green (which retained its vibrancy on dark backgrounds) and blue (which retained its vibrancy on light backgrounds).

Content text colors

Content text colors were used on copywriting that people needed to read and understand—these can also be called “essential texts” by WCAG’s definition.

Decorative colors

Decorative colors were vibrant colors for supporting graphics that enhanced the page's messaging.

Utility colors

It was important for the team to prepare for use cases where users needed straight forward feedback from things like a signup form. These colors were coordinated with Product Design to help maintain a consistent feedback experience across Product and Marketing.

A consistent look and feel

The semantic color roles we defined helped us create a solid look and feel between different cross-functional page templates. 

Product pages

These pages are maintained by the in-house Web Engineering team, and the content is owned by the Product Marketing team.

Partners Portal pages

These pages are maintained by a third-party vendor, and the implementation of the new look and feel was coordinated with the Partner Marketing team.

Documentation Home page

The Documentation domain is maintained by the Web Engineering team, and owned by the Product Design team. The Product Designer was able to use the new color system and component library to produce a new Documentation home page that looked similar to the Marketing look and feel.

Although not 100% accurate to one another, the domains seemed close enough to feel unified. The teams are however interested in continuous refinement to make the domains more alike to one another.

A more scalable process

Here are some of the high impact outcomes that resulted from my work:

1. I led the creation of an automated, accessible color theme. This reduces the time to publish to (5) days as opposed to (10) days.
2. Designers can more easily identify accessible color combinations. This could reduce the time to produce designs to (3) days as opposed to (10) days.
3. We are able to identify inaccessible color combinations and switch out color tokens on the website in (1) day as opposed to (10) days.

We do still have challenges around simplifying the theme even more—the color relationships within a color block theme grow exponentially if the number of relationships are not constrained. While we want to simplify the theme, we have also been wary of “blandifying” the new visual look and feel.

Looking forward

The website rebuild project is still ongoing and there will be more case studies that build on top of this one. The other parts of the process will go deeper into topics like:

• Building web components that are accessible, dynamic, and fun.
• Refining the design to development hand off.
• Running qualitative tests to challenge our initial design hypotheses.