TOKENS, PALETTES, AND THEMES
a design systems project for Understood (2020-2021)
Problem space
Dark mode as a lever for flexible theming
Initially, dark mode was an accessibility-minded request from leadership meant to accommodate vision-impaired users on our site. However, our tech organization also envisioned it as a first step towards creating discrete themes beyond light and dark mode, allowing us to arrange our components by function and base a component’s branding on where it’s implemented.
I plotted out dark mode manually before codifying, eventually discovering that light mode background colors follow a pattern called “altitude”, where containers continually become lighter or more saturated as they nest deeper and deeper, making dark mode easy to plot in a more monochrome way.
An example of “altitude”. Layers are considered higher or lower surfaces based on how deep they nest, with each “level” corresponding to a different color in dark mode.
Technical approach
A design-led pipeline built on tokens
In order to implement theming, we created our own tokens framework using CSS color variables named after a color’s purpose rather than its appearance. We then plugged them into Figma’s Themer plugin in order to test how well designs translate into dark mode in Figma.
One of our developers then hand-built a version of Themer that ingests colors from Figma, translates them into a format that our tech stack can consume more easily, and sends the updates to GitHub. With this workflow in place, designers would in theory be able to change colors in design and pass them straight into code without assistance.
Developer feedback, workflow analysis
New tokens were hard to use and understand
In the months after launch, I had been asked by almost every member of our front-end team how to match palette changes in designs in the codebase, as technical documentation did not yet exist. After meeting with the engineering team, it turned out that this tokens system actually created more work for the developers than it saved, and I was given the feedback that more time and training was needed before implementation would be possible.
Adapting to technical needs
proven solutions that scale
Shortly after discovering our workflow gaps, it was announced that our our tech team would be adjusting front-end web frameworks, and that we slated to build a mobile-native app in the near future. Our tokens system was specifically meant for web use, so we had to pivot more quickly than we’d be able to adjust our bespoke system.
We decided in this case not to reinvent the wheel, and in order to scale with our products, we adopted Amazon’s Style Dictionary in order to export styles to any language, as well as Zeroheight to directly patch our palette into our code and act as a single source of truth in documentation.
Finally, we decided to extend our use of tokens from basic style declarations to fully styling components using tokens. This way, we could make use of Style Dictionary to export more complicated items across platforms without having to rewrite code.
A mismatch of needs
Designers had trouble accurately employing our color palette
While this new tokens pipeline was being built, it was revealed that our designers did not find the color variables intuitive. Variables were understood as static names assigned to multiple colors, and designers often just guessed which colors to use without checking in dark mode.
To make matters more complicated, the product suite updates were accompanied by visual identity updates that our somewhat-constrained variable palette no longer reflected. It became clear that we needed a system that freed designers to use our full palette to accompany more blue-sky product design.
Applying traditional UX concepts to design systems
Workshopping, testing, and implementing a palette that works
In order to arrive at palette consensus, I gathered our whole UX and front-end teams and led a workshop to find a color system that worked for all of us. We started with a purely generative session that concluded with a vote on which system best met everyone’s needs. I then built that palette in Figma and shared with the team to test for the following two weeks.
After only one round of feedback, we settled on a new palette, which we use to this very day. It preserves the technical approach we developed based on engineers’ feedback, but allows designers to use every color in our brand, this time based explicitly on the concept of altitude that our dark mode started with.
Background colors in the old tokens system vs the current one. Despite the larger number of themes in the older system, the newer palette includes all of our brand colors, doesn’t separate them based on setting, and gives the designer more control over how each color appears in dark mode.