On the surface color seems simple, but getting 100+ designers and engineers to follow guidelines that are a part of literally everything they make is a huge undertaking. To put it in perspective: over 50% of Lyft’s design system team’s office hours, high visibility projects and inner team disagreements are color related. We’ve learned a lot over the past three years. It sure as hell ain’t perfect, but it’s working pretty well so far.

These are the constraints that defined the construction of our system and the top issues we commonly face:

Constraints

A system constrained to AA accessibility for a complex product will be constructed differently from a system with no accessibility requirement for a simple one.

To determine how to construct your system, consider the following:

Accessibility

Color accessibility means contrast between an element and it’s background — how easy it is for everyone to read text or see an icon. There are two WCAG 2.1 levels that have different contrast requirements for icons, interactive elements, large and small text. Level AA is a legal requirement for most architecture, transportation or government-based companies. It’s important to note that the guidelines are written for and need to be upheld by the web, but can be applied to mobile.

• Ask your leadership, legal or accessibility team which WCAG level your product has agreed to meet.
• If the company hasn’t considered accessibility before your conversation, get leadership to make it a requirement before baking it into the system. Getting feature teams to choose the more accessible design over the more visually beautiful one is near impossible when the only reason is it’s the right thing to do.
• Get a color contrast checking app to be given out as part of onboarding. We recommend Contrast for Mac, built by Sam, or A11y — Color Contrast Checker for Figma.

Flexibility

The most flexible system would be to allow any hex value, but this makes it hard to maintain consistency. Before the Lyft Product Language, there were 15 variations of Lyft Pink within our app.The most rigid system would be only allowing a small amount of colors used for very specific use cases. This can result in designers feeling like they’re losing clarity for the sake of consistency.

Complex products are a balance — common colors that cover most the majority and valid use cases where a larger variety is needed.

Build a more rigid system if color usage can be clearly documented and there are very few use cases that currently break the system. Build a more flexible system if color usage is complex, like having large data / graphs, marketing, sub-brands and/or programs.

Expansion

Products can start small and expand into multiple brands, sub-brands and modes. When we first created our color system we did not consider dark mode or re-branded versions of the app. Each addition required the system to be rebuilt more generically — we went from a specific system to a themed one.

Keep color names and aliases as generic as possible and build a way to easily switch between brand and mode directories for complex products. Be as specific as you’d like with simple ones.

Construction

Construction relies on what you know and what you can anticipate. Most design systems cover common use cases because they are known. Anticipating the need for additional colors and incorrect hexes or usages makes the system more bulletproof.

Spectrum

The spectrum, created using Color Box, offers tints and shades in each color range to cover all use cases. Colors are named for ease of identification and numbered on the 10s to offer the ability to add more tints and shades in-between in the future, if needed. To stop designers and engineers from using slightly off hex values, ensure that the spectrum is easier to reference than the eyedropper tool. Programs like Figma have made creating, maintaining and using color libraries easy.

• Accessibility It is incredibly hard to build accessibility into the spectrum because of the different WCAG requirements for different elements and varying contrast levels for different colors (ex: yellow has less contrast than blue.) Feature designers choosing to use colors from spectrum must be held accountable to remain accessible, ideally by their team and leadership.
• Flexibility The spectrum offers the flexibility of the rainbow, while maintaining the consistency of identifiable names to a subset of hex values.
• Expansion A light and dark spectrum with the same name for colors can be created to easily swap between light and dark mode.

Palettes

Palettes are collections of spectrum colors, given future-proof aliases, that are used most often in the product. Text, icon, surface, background, and stroke are common palettes. Ensure that the palettes are easier to reference than the spectrum and the eyedropper tool.

• Accessibility Text, icon, and stroke palettes must be designed to be accessible when paired with the surface and background palettes. When a designer uses palettes they should feel confident that it is accessible.
• Flexibility Palettes are more rigid because they denote specific uses for colors. In a very rigid system designers can only use palettes that must cover all use cases. In a more flexible system, with both spectrum and palettes available for use, designers should be encouraged to only use spectrum when their use case isn’t covered by the palettes.
• Expansion Palettes aliases make re-branding the app simple. Each brand keeps the same alias names and swaps out the spectrum colors used.

Linters

A linter is a tool that analyzes code to flag system violations. Create linters in commonly used programs, like Figma and Github, to ensure designers and engineers are using the palettes consistently. Our Figma plugin scans a file, outlines what colors are off, and offers to snap them to the closest palette or spectrum color. In code our linters require the color be fixed before code can be pushed live.

• Accessibility Using linters is the only way to ensure your product is meeting color contrast accessibility requirements.
• Flexibility Linters are the definition of rigidity for consistency. Offer education (why it’s a requirement) and quick fixes (like snapping to the closest spectrum or palette color) to avoid increasing the need for hands-on support.
• Expansion It is easy to add or change linters as the product evolves.

Top Issues

We talk with feature designers the most about how to use brand colors in product, how a vibrant feature color can disrupt the main flow goals, and how a feature shouldn’t own a color.

Brand Color Usage

For many products the predominant brand color is used for the main call to action. Blue brand, blue buttons. Unfortunately that isn’t always possible. Lyft’s particular hot pink does not meet the 4.5:1 accessibility constraint when used as the background of a button. When we had to choose between a darker pink or a vibrant purple, we chose purple. However there are two potential problems with a different main call to action color than your brand color:

• Repeatedly defending the rationale to new brand & product designers. We’d even encounter engineers styling the purple button component to be pink and designers using the brand color for other UI.
• The color used most frequently in the product can define the brand. Make sure your brand outside of the app is strong enough that users still associate you with the desired brand color.

Screen Goals & Hierarchy

The proportions of color on a screen helps define the hierarchy. Redesigns’ hierarchy are so clear because the designers on them are defining goals and ranking features for each screen holistically. When different teams own separate features within a screen they fight for hierarchy typically using size and color. Due to the screen size and amount of content, features may only have a small amount of space so they fallback to color to make it stand out. The result is a rainbow app where every feature is trying to win over the user.

• Encourage teams to have clear goals documented for every screen within a main flow.
• Feature teams should get agreement from the product platform team or leadership on the level of importance of their feature before designing a solution.

Exclusive Use of Color

Product teams love to create features that exclusively own a color. The idea is to have the user quickly associate the color with the feature throughout the app. This is possible if the color is used frequently and consistently to mean the same thing — but there are only a handful of distinguishable colors and usually another team is using it to mean something else. With only a few colors left (once you remove the main color & statuses), most features cannot be important enough to stop all other features from using a color.

• Assess the importance of a feature by referring to the screen goals / hierarchy when compared to other features.
• Suggest adding extra oomph in other ways, like iconography or styling.

Last thoughts

Getting leadership to align and buy-in on the constraints and top issues early will help you out in the long run. If they can socialize the guidance outside of the system then the support needed won’t fall solely on the design systems team’s shoulders.

This color system was created over 3 years by the Design System team at Lyft. Special shout-outs to Kevyn Arnott, Evan Maeda, Alex Lockwood, Kathy Ma, Gabriel Lanata, Jeremy Dizon and Sam Soffes. I’m Linzi Berry, currently product design manager of the team. My hope in documenting system design thinking and process is to contribute and learn from the design community at large. Please subscribe!