Unit 1: Intro to Design
Unit 2: Figma Fundamentals
Unit 3: The Creative Process
Unit 4: Color Theory
Unit 5: Introduction to Illustrator
Unit 6: Typography
Unit 7: Layout
Unit 8: Typesetting
Unit 9: User Interface Design
Unit 10: Design Systems
1 of 2

Colors in Design System

Color is arguably one of the most important elements in a design system. In this lesson, we will talk about how to prepare colors for your design system.

Organize all of your colors

For most design systems, colors could be structured in 4 groups — Primary colors, Secondary colors, Neutrals and Semantic colors.

1. Primary colors

These are the colors that are most frequently used across user interface and imparts a distinct identity to the product. These are usually the colors that a brand sets as their identity. Using brand colors as primary colors strengthens brand awareness.

For example. LinkedIn has a medium saturation and brightness type of blue as their primary color. Airbnb has a red color that is a little on the orange side as their primary color and Twitter uses a sky blue color as their primary color.

https://miro.medium.com/max/1400/1*NY2DtYxbGxzFVqeOhh70Sg.png

2. Secondary colors

These colors highlight or complement the primary color. These are to be used sparingly to make the UI elements stand out. These colors are also usually defined in the brand guidelines.

Usually, a brand may have 1–6 secondary colors, although limiting it to three colors would bring in more recognizability and consistency.

If your organization has multiple products in its portfolio, each of the sub-brand (or product) may have its own set of primary and secondary colors.

3. Neutrals

These include shades of gray, all the way from White to Black. These are used for backgrounds, text colors, etc, and form the majority of your UI.

https://miro.medium.com/max/1400/1*5X1Rpw1Z5zrarxzP2v0krw.png

4. Semantic or System Colors

These are the colors that communicate purpose. They help users convey messages. For example, Green has a positive connotation. We use Green to convey success, confirmation messages, etc. Red usually signals an error state. Orange or yellow usually means a warning message and blue is more for information or default link colors. These colors are sometimes called system colors.

https://miro.medium.com/max/1400/1*Z7Rwkz9hvB2YsCgQ4lR5Nw.png

Create extended palettes

In addition to the base colors we mentioned, we may need additional shades of the base color to cater to varied use cases. Once the primary, secondary and semantic colors are identified, the next step is to define a system that will allow you to generate additional shades from them.

https://miro.medium.com/max/1400/1*rQBr9fRYnMWvfJ8DT0XXDA.png

Extended palette generator

Although designers can create tints and shades of the same base color manually by adjusting saturation and brightness using the HSB color model, there are some online tools that can help speed up the process — one of them is Colorbox. It makes creating color systems very convenient while allowing us to tweak the parameters to suit our own needs.

https://miro.medium.com/max/1400/1*RiWJSxkMuhKdiYOP0UmN5A.png

To create a consistent harmonious color system, color palettes must be created using a defined algorithm that takes into account all dimensions – namely Hue, Saturation, Brightness.

Let us see how Colorbox can help us do that:

  1. No. of steps: This defines the number of swatches in the palette. 10-11 steps is a good number to start with.
  2. Lock base color: Input the base color, variations of which you wish to create (this could be primary, secondary, or semantic colors)
  3. Define hue variation: This dictates how the hue will vary across the swatches in the palette. You may stick with the hue value of the base color throughout all the swatches or add a slight variation.a) First, define the hue values for swatches at the extreme ends b) Next, select the curve (Linear / Cubic / Sine…). The curve dictates how hue values would vary between the extreme swatches. Play around and then select.
  4. Define saturation variation: The same process for hue goes for saturation and brightness as wella) Firstly, define the saturation values for swatches at the extreme ends (I prefer 5–100, as it provides light shades to be used for backgrounds.b) Next, select the curve (Linear / Cubic / Sine…) that will dictate the saturation values for swatches in between the extremes.
  5. Define brightness variation: As we move down the palette the brightness shall decrease. a) A range of 100 to 35 would cater to most of the colors, though you may want to tweak the end value for some.b) I recommend using the linear curve if you want a consistent jump in brightness moving from one swatch to the next.

That’s it. You have your color palette ready.

It’s good practice to use the same settings of saturation & brightness for all of your base colors. These would lead to a harmonious color system.

Trim down on color shades

By the end of the previous exercise, you will end up with lots of color shades. Each color palette will have around 10–11 swatches. Though, you won’t require all of those. Analyze the use cases for colors and trim down on the number. It would do two wonders. Firstly, it will reduce the cognitive load for the designer and enhance decision making speed. Secondly, it would be far easier to maintain the color system.

https://miro.medium.com/max/1400/1*jwPxUXFaWsQ19kNb0zACCA.png

Establish naming conventions

Communicating with stakeholders in logical, understandable names like ‘primary color’ is much easier than communicating in hardcoded values (#1F6AE3).

What’s even better is that these names may double as Design tokens. Design tokens are named entities that store visual design attributes (spacing, color, typography, etc). These are used in place of hardcoded values to build and maintain a scalable, consistent design system.

https://miro.medium.com/max/1400/1*KXMOwRup8BsNvyMGrdxmhA.png

https://miro.medium.com/max/1400/1*OoSa0LFTh3-Hm8ce29yvUw.png

So how do we name colors? Our color palettes are comprised of a base color and extended palette. The extended palette includes the additional shades generated from the base color.

Colors are named as ‘Color label-XX’ (for ex. primary-100)

The color label represents the base color, while the ‘XX’ number represents different shades. It is highly recommended to name colors based on their functions and not the hue. Ex: Primary, Success, Error instead of Sea green, Green, Red.

Here’s how the value of XX is determined — Base color: 100 Shades darker than base color: >100 Shades lighter than base color: <100

https://miro.medium.com/max/1400/1*UVwvL07xh8memBpPbLLr5Q.png

https://miro.medium.com/max/1400/1*snFUcCZfdZJ7-pORfbN8Aw.png

Validate new color palettes

By now you should have palettes for primary colors, secondary colors, neutrals, and semantic colors. Ideally, these palettes should cater to each and every UI element in your design.

To validate colors, identify few key UI journeys of your product. Next, start replacing the colors in your design with newly created colors. Ensure that you don’t miss out on anything — background, text, etc. Check if the colors are serving the purpose they are intended to. For example, a secondary color must stand out to grab user attention.

Another important consideration is that of accessibility. Check if there is sufficient contrast between the background and text elements. You should strive to comply with WCAG Color Contrast guidelines. Here’s the snapshot of the guidelines. To learn more about accessibility, we strongly recommend taking our Design for Accessibility course.

https://miro.medium.com/max/1400/1*vDmiQhDV6mgJuoJA64h2Ww.png

UI elements with the sole purpose of decoration and disabled elements need not follow this guideline.

Stark is a handy plugin that’s available for most design platforms including Figma, Adobe xD, Sketch and the browser. It will allow you to effortlessly check if the colors meet accessibility standards.

Define usage guidelines

Simply restricting designers to select from a predefined set of colors would not bring consistency. We need to take a step ahead by defining the usage guidelines for these colors.

Which shade should I use for secondary text? What should be the background color of CTAs?What colors are to be used on disabled elements?

Our job should be to ensure that all designers or developers have the same answer to each of these questions. IBM does a great job in defining color usage guidelines in their Carbon Design System.

Release for testing

Design systems may wither if not accepted or implemented in their true essence in an organization. The sooner you onboard stakeholders to the design system, the better it is. Everyone’s support and inputs would make this a system that keeps evolving into a better one.

Push the defined color palettes along with usage guidelines to the stakeholders. Stakeholders may test the same in few of the UI journeys and validate the color system. Incorporate their feedback and make iterations to the color system if required.

Collaborate with developers

In the process of establishing your design system, it is a great idea to get developers involved because they could add valuable insights into what works and what doesn’t. There are certain ways of organizing the design system that could make it easier for them to do their job.

When developers incorporate the design system, especially design tokens into their development workflow, it will improve the efficiency of code tremendously. For example, if you were to change your primary color from sea green to sky blue, just a change in a single line of code will implement the new primary color in all the UI elements.

Light and Dark Color Modes in Design Systems

In recent years, as user interface design evolves to accommodate more user preference, freedom of customization and improved accessibility, there is an increasing need for both light and dark color modes. Some users prefer to view everything in light mode while others prefer dark mode.

As we establish our design systems, consideration for the light and dark variables has become a necessity.

Let’s take a look at the steps we can take to set up such a color system.

Prepping for a Light & Dark System

Inventory Neutrals Use Across Components

Before selecting new colors, inventory the neutrals you already use. Some libraries already limit a small set of tints, but make a note if the number of neutrals get too large. There is no magical number as the threshold, but generally speaking, if the number of neutrals start going beyond 12, it should be considered a bit too many.

https://miro.medium.com/max/1400/1*yYsFkvJ7doEePKyj4Wb4pw.png

Catalog the distinct HEX values of these neutrals, order them from light to dark, and prepare to prune to a reasonably-sized, non-duplicative, harmonious set.

Next, analyze color use across components to understand how neutrals are applied as text, background, and border colors. Look for patterns as well as inconsistencies. Are the neutrals harmonious? Is the primary text using 3, 4, or even 5 different neutrals? Does the benefit of all this variety outweigh the cost of complexity and variability?

Arrange Component Designs Across Backgrounds

The next step is to stack your library’s more basic components densely on a white canvas. Then duplicate the stacked column for each background color your system needs, like this.

https://miro.medium.com/max/1400/1*lWxTIKAJgho2k8k60_i8Lw.png

With this setup, you can experiment with and demonstrate effectively designed components across backgrounds.

Light & Dark Properties

For the next step, we need to determine how many types of light and dark background we really need for our design system.

Background Color: Just Light and Dark Settings, or More Options?

Most teams opt for a simple toggle: a “light”, often pure white #FFFFFF canvas and “dark”, near black canvas such as#222222.

https://miro.medium.com/max/1400/1*Ka8eOXXmgQBb2KZG5tJQ4Q.png

Other teams endorse a wider range of neutral backgrounds. For example, a system may overlay light gray modules on a white canvas (or vice versa, or both). In a dark setting, there may be a “pure black” alternative for a video player and photo gallery distinct from the default charcoal dark background. Therefore, having a pair of colors for each of light and dark is helpful.

https://miro.medium.com/max/1400/1*LWP7Op9SPz8zsTkJw_7JZQ.png

A very sophisticated collection of layered backgrounds could start with white and near black and add successive layers of darkening light grays and lightening charcoals, respectively.

https://miro.medium.com/max/1400/1*rLqpWVD1Z0lcZgrygw1tcA.png

Even if you target just two settings (“light” and “dark”), expect to solve for a background color shift in each setting. Finally, avoid ballooning the complexity of colorful and photography backdrops, at least early on.

Text Color: Type Your Types

There are several categories of text in a typical user interface:

  • primary text color for paragraphs, labels and other essentials
  • secondary text color like form microcopy, captions, and table headings
  • interactive text like links
  • inlineerror text color shown adjacent to controls
  • disabled text that is grayed out, usually in form controls and buttons

An icon fill/text color could be included too, or you can color icons using the same primary, secondary, and interactive types already in play.

https://miro.medium.com/max/1400/1*MO7F5hDOB8fEjBSQ-Vb-Kw.png

One thing is for sure: finding link and error text color in dark settings that’s both accessible and harmonious is difficult. Often times it is easier to define “use white” for those types on dark.

https://miro.medium.com/max/1400/1*IESHBuc4PEIKjxMvfzS1uQ.png

It is important to first identify a simple classification of type color that includes at least primary, secondary, interactive, and error text. Then we can more cautiously consider additional types such as tertiary and distinct icon fill colors.

Borders of Controls: Keep Strokes Strong Enough

Input controls — textbox, textarea, radio-button — require strong contrast for visibility and usability. The control’s border color can play a big role, and may or may not shift across backgrounds. Other features – a :focus halo, a red border for field in error, and more – may also need attention.

https://miro.medium.com/max/1400/1*fco3n9U3HRIIlEzkE_0owA.png

Consider the borders and focused states of UI controls, and see if a moderate neutral and identical halo is usable across all settings.

States: Adjust by Shifting Opacity

Don’t forget interactive states like the hover, active, and selected states of buttons, tabs, list groups and links.

https://miro.medium.com/max/1400/1*O5S0EyDDcXuU17jb70ecJw.png

As with color in general, states are a place where functional transformations (think: darken(5%)) or adjusted opacity (think: background-color: rgba(x,x,x,80%)) can work well. Other teams handpick even these colors, optimizing appearances per background.

Backgrounds on Backgrounds: Prevent Undesirable Layering

Things get more interesting when a component block — like a card — has a neutral background that itself rests on a different neutral.

Suddenly, you are solving for text on a background … on a background.

https://miro.medium.com/max/1400/1*_-PRL9nUfawe3NKT4Nb8Hg.png

Make sure to tweak neutral colors so that they can still be differentiated from each other in both light and dark modes.

Further Considerations When Implementing Light & Dark Color in a Library

Accessibility: Stay Tuned in Real Time

As you select color combinations, keep an eye on accessibility. You can adapt colors to different background schemes as aesthetically-need but make sure to stay within accessible contrast that passes the contrast checker.

Scroll to Top