import Video from "./components/Video" import Flex from "./components/Flex" import Img from "./elements/Img" import Div from "./elements/Div" import BlockLink from "./components/BlockLink" import Logo from "./components/Logo" import Span from "./elements/Span" import { FigureLink } from "./components/MDXWrapper"
Color is my day-long obsession, joy and torment - Claude Monet
Over the last two years we’ve tried to improve our usage of color at Cloudflare. There were a number of forcing functions that made this work a priority. As a small team of designers and engineers we had inherited a bunch of design work that was a mix of values built by multiple teams. As a result it was difficult and unnecessarily time consuming to add new colors when building new components.
We also wanted to improve our accessibility. While we were doing pretty well, we had room for improvement, largely around how we used green. As a lot of our interface is increasingly centered around data visualizations featuring large data sets we wanted to push the boundaries of making our analytics as visually accessible as possible.
Cloudflare had also undergone a rebrand around 2016 and while our marketing site had rolled out an updated set of visuals, our product ui as well as a number of existing web properties were still using various versions of our old palette.
Our product palette wasn’t well balanced by itself. Many colors had been chosen one or two at a time. You can see how we chose blueberry, ice, and water at a different point in time than marine and thunder.
Lacking visual cohesion within our own product, we definitely weren’t providing a cohesive visual experience between our product and our site for our customers. The transition from the nice blues, purples, with a nice accent color to our green CTAs wasn’t the streamlined experience we wanted to afford our users.
Our first step was to audit what we already had. Cloudflare has been around long enough to have more than one website. Beyond cloudflare.com we, like many companies have dozens of web properties that are publicly accessible. From our community forums, support docs, blog, status page, to numerous micro sites.
All in all we have dozens of front-end codebases that each represent one more chance to introduce design entropy to our system. So we were curious to answer the question - what colors were we currently using? Were there consistent patterns we could document for further reuse? Could we build a living style guide that didn’t cover just one site, but all of them?
Our curiosity got the best of us and we went about exploring ways we could visualize our design language across all of our sites.
A time machine for color
As we first started to identify the scale of our color problems, we tried to think outside the box on how we might explore the problem space. After an initial brainstorming session we combined the Internet Archive's Wayback Machine with the css stats api to build an audit tool that shows how our various w'ebsites visual properties change over time. We can dynamically select which sites we want to compare and scrub through time to see changes.
Below is a visualization of palettes from 9 different websites changing over a period of 6 years. Above the palettes is a component that spits out common colors, across all of these sites. The only two common colors across all properties (appearing for only a brief flash) were #fff and transparent. Over time we haven’t been very consistent with ourselves.
If we drill in to look at our marketing site compared to our dashboard app - it looks like the video below. We see a bit more overlap at first and then a significant divergence at the 16 second mark when our product palette grew significantly. At the 22 second mark you can see the marketing palette completely change as a result of the rebrand while our product palette stays the same. As time goes on you can see us becoming more and more inconsistent across the two code bases.