In the Winter of 2021, as Design Systems Lead at Carta, I overhauled our color palette and scaled our design system to accommodate Dark Mode.
In Spring 2020, I became Design Lead at Carta, Stanford’s official course exploration platform used by 95% of undergraduates.
In Winter 2021, in my newly acquired role as Design Systems Lead, I worked to revise our color palette to help smooth over many of the issues we were running into in our higher-fidelity designs.
Before long, this overhaul extended to solve the Dark Mode problem – creating a scalable color system to accommodate theming!
For data-viz screens, our team had no clear direction for how to color our data.
With plans to implement an immersive course-planning experience on the platform, we were unsure how to dovetail our data-viz colors with course-categorization colors.
A huge blocker for solving these problems was our current palette, which offered no guidance to navigate these problems.
Reviewing the current palette, auditing other design systems and identity guides, refining the palette.
Our current color pallete had been pulled almost completely from Material's color tool – an assortment of tints and shades across the color spectrum. Our only deviance was the red section which harnesses the Stanford cardinal red hue.
For each hue, stars cue the designer into what color they might want to use for primary use cases.
The gradations for each hue give designers flexibility to utilize a wider range of options in secondary use-case scenarios.
Designers are left with a large amount of freedom to choose colors for different purposes. I worried that this might lead to disjointed experiences and – based on my own experience using the palette – that it might make choosing what color to use during high-fidelity designs unnecessarily hard.
To refine our color palette, I first perused various design systems elsewhere to analyze the trends I saw and the justifications behind the decisions that were made.
Perhaps the highest-level piece of guidance offered, documentation stressed the importance of thinking of color as a tool for user comprehension rather than user delight. To this end, Latitude stressed the sparse use of color (to reduce visual fatigue as well).
All palette's encouraged a strict adherence to accessibility guidelines. The WCAG 2.0 minimum contrast ratios were frequently cited throughout as mechanisms for determining color-combinations and the palettes themselves.
Palettes varied in organization, but a pervasive theme was the consistent mapping of colors/hues to their roles. Atlassian outlined the semantic meaning of their colors in a chart shown below.
Companies also harnessed color to emphasize and embolden their brand. When there is a primary category within a color palette, the brand-specific hues are sure to be included!
During our redesign last Spring, Carta decided to increase credibility by aligning with Stanford's visual identity. We've striven ever since to strike a balance between users recognizing us as an official Stanford resource and simultaneously a modern, sleek, consumer-facing product.
Adhering to the Stanford brand was always a non-negotiable of the palette refinement, but I knew that harnessing the official Stanford Identity Guide could further that alignment much more than our current palette.
Combining all of my insights, I constructed a new color palette to match our goals for brand-alignment and designer usability.
I decided that it was necessary to use a more vibrant variation of the Stanford red to increase visibility for CTA's and breath more energy and friendliness into our interfaces. I also decided to incorporate the "Light" variation in the case of Dark Mode in the future.
4 entire gradations were assigned explicit semantic roles within our interfaces. This would greatly reduce designer decision fatigue when selecting for feedback states and other use cases. For the error hue, I iterated through red-orange hues to arrive at a color that resonated with traditional red error states while still maintaining a recognizable difference from our Stanford red color.
To deal with potential scalability needs in the future and edge-cases where our semantic and brand colors might not fit the bill, I knew a complementary set of hues was necessary. These accents were derived largely from the Stanford identity guide so as to promote brand recognition, while avoiding colors that might be too similar to my previously chosen hues. To establish a more accurate mental model of the brand, I highlighted a primary accent color based on Stanford's logo.
The team appreciated the Stanford-specific approach to color. This was OUR palette, not Google Material's.
Our designers liked this transition from the color-naming to the role-naming convention because it gave them clarity for which hues to use for which use case.
All of this is nice, but the palette still needed to account for the data-viz issues we were grappling with.
Auditing analogous products and documentation, iterating solutions, gaining team buy-in, calibrating for accessibility.
Our team had struggled for weeks to find a color approach for our data-viz sections, specifically in our Individual Course page, where data is heavily used.
Without any experience in the subject, I knew that conducting external audits was my best bet.
In EVERY case, the primary color used in data-vizualizations was the primary brand color. If there were multiple hues in a graph/chart, the second color was usually the secondary brand color as well.
I also went back to some of the design systems that I'd researched to learn more about how they approach data-viz and color.
Certain accessibility guidelines were common – dial down vibrance to reduce eyestrain, maintain 3:1 color contrast ratio between adjacent colors, etc.
Armed with these insights, I took a brand-centric approach to our data-viz page, implementing the learnings from my audits.
Choosing Cardinal Red as a primary data-viz color made most sense because brand alignment was paramount. I reasoned that error-state confusion was an acceptable sacrifice because, among other reasons, our error-state color across the platform was recognizably different.
I relied on Shopify's and Mailchimp's documentation for data-viz colors where multiple adjacent colors were needed. In sum, varying hue/saturation/luminance while checking for 3:1 ratios between adjacent colors. I used my Accent gradations from my new color palette.
Confident in this direction, I pushed three variations in front of my Design Co-Lead.
My Co-Lead struggled to get past the fact that, simply put, the page was so red.
This piece of criticism arose from my reliance on our aqua-green brand-accent color.
In an attempt to get team buy-in for the brand-centric direction, I then prepared a presentation for the team, so as to make sure I'm methodically communicating my audits, insights, and justifications.
I made sure to create several permutations orthogonal to the brand-centric approach to facilitate more robust feedback and account for my Co-Lead's critiques.
Having seen the screenshots from my audited data-viz products, it became clear to the team that Cardinal red as the primary data-viz color was a sensible choice.
The Cardinal red variations that I presented featured a different shade than the Cardinal red color specified in the Stanford Identity Guide (in an attempt to reduce eye strain). This deterence from the brand might actually detract from brand recognition and create comprehension issues, worried my teammates.
In some of my designs, pairing Cardinal red next to aqua-green might lead to confusion. "Wait, so 96% completed and 4% withdrew, but why is 'Withdraw' green and 'Completed' red??".
Some teammates favored blue over aqua-green ("too christmas-y!"), while others disagreed.
Keeping feedback top-of-mind, I moved forward with a refined treatment for data-viz.
For the primary data-viz color, I chose the Light variation for Cardinal red taken from the Stanford Identity Guide. This color offered a reduced vibrance (and thus reduced eyestrain) compared to previous options as well as 100% alignment with brand.
At the cost of "Christmas" associations, I chose our brand accent color for our secondary data-viz color for brand prioritization. To combat red-green semantic confusion, I used a lighter shade of the Light Cardinal red hue in relevant cases.
Since accessibility was the goal, I used the CIELAB (a perceptually uniform) color space to calibrate perceived brightness, tweaking the colors in my data-viz palette for multiple colors to maintain disparate luminance values.
I considered applying CIELAB calibrations across the entire color palette (inspired by a case study published by Stripe), but, alas, there was no sufficient tooling publicly available.
Performing secondary research, interfacing with Front End, prototyping solution, reviewing with Design, constructing new system.
Since our Front End team was still in the earlier stages of production, they told me that if we're ever going to do Dark Mode, we need to implement it now.
Today, users, especially our college-level user base, almost expect Dark Mode as a feature within popular products. Implementing Dark Mode is an opportunity for Carta to establish itself as a credible and highly refined product. Besides, who doesn't like Dark Mode?
As I had just finished my work on the color palette, this was a sensible next step in my work.
I sifted through case studies (including Outlook and Etsy) and articles to get a grasp for how companies are scaling their systems to accomodate Dark Mode.
While shadows communicate elevation on light mode interfaces, a darker theme necessitates lighter shades to communicate higher positions. For color, increasing luminance and dropping saturation can avoid clashes that arise between dark surfaces and saturated hues.
A semantic system, wherein a single token named for its role (i.e., $background) maps to a single color value given a theme, was frequently cited. I.e., $background in Light theme = #FFFFFF, whereas in Dark theme, $background = #000000.
The thinking is that there exists a single source of truth for a brand's color values, and a subset of that palette is used to comprise a theme.
During my seconary research, I came across Themer, a highly popular Figma plugin that allows quick swapping of themes within a team library.
Initial testing proved that this could work. Within a few minutes, I could quickly toggle an interface from Light mode to Dark mode, I just had to make sure my styles were wired up correctly.
Research + plugin in hand, I presented my findings to the front end team and asked them what their workflow ideally would look like to make Dark Mode happen.
They confirmed the necessity of the semantic colors + tokens for their theming workflow.
While it might be nice to give designers freedom to use whatever color they want and not have to conform to a semantic system, this would drastically increase the workload required of engineers during implementation.
– Lead FE engineer
During further research, Front End confirmed that IBM's design system, Carbon, was a shining example for implementing a semantic system with color tokens for theming.
I cited Carbon's "White" and "Gray 100" themes regularly as I began to prototype a system to present to Design.
Now that I knew the ideal workflow for Front End, I took my learnings back to the design team to address potential painpoints and gauge alignment. I still worried that a semantic structure would severely constrain my designers.
Reviewing my takeaways from my meeting with Front End, I presented a proof-of-concept showing the system and plugin in use.
Surprisingly, my design team immediately grasped the merits of the semantic system for the sake of theming. Even more, this new structure would make their Light Mode designing easier, as it reduced decisions and increased guidance.
– Design teammate
After a week of testing and tweaking on some higher-fidelity screens that we had ready for production, I arrived at a robust set of themes for Light and Dark.
After syncing back with Front End to onboard them onto the new system, I onboarded my design teammates onto the new workflow, toggling back and forth between high-fidelity screens to show the convenience of the Themer plugin and ease of system use.
Since all of our designers would be designing in Light Theme, I adjusted my internal naming (harnessing Figma's alphabetical sorting) to make sure Light Theme is at the top of the style pop-over, reducing scrolling required on the designer's end.
The current Light and Dark themes couldn't possibly account for all of the semantic color tokens that our platform will need. To account for scalability, I added a Review page to the Light Theme file to handle new token requests from designers.
In the end, I was able to create a scalable system that is easy to use for both designers and engineers! Dark Mode was a daunting task, but with the help of my teammates, several articles and pieces of documentation, and a nifty-little plugin, I was able to make it a reality for Carta!