How to Avoid Adding Too Many Colors to a Design System
As a design system grows, teams may keep adding almost identical pale blues for page backgrounds and slightly different blues for buttons. Eventually nobody knows which color should be used. A design system is a shared set of rules for creating and reusing interface components, colors, and other design decisions. Avoiding color proliferation is not about setting an arbitrary maximum. It is about combining colors that perform the same job while preserving distinctions that are genuinely needed. Here is a practical method, using a support-ticket dashboard as an example.
Check whether a color has its own role before setting a limit
If two departments use different colors for ordinary body text, notes, or primary buttons, the values are candidates for consolidation. Success and error states, on the other hand, communicate different outcomes. Forcing them into the same color merely to reduce the palette can make those outcomes more difficult to distinguish.
A useful sequence is to identify the colors actually used in the product, group them by their role (background, text, action, or status), compare values with the same purpose, and test the real foreground/background combinations before merging anything. Similar-looking colors should not automatically be combined: replacing text on a dark panel with a lighter standard text color could reduce its contrast.
The number of named roles need not equal the number of unique color values. For instance, white used as a card surface and white used as text on a button can have separate role names, even when they happen to share the same value today. Their roles might need to change independently in the future.
Consolidate duplicate colors in a support-ticket dashboard
Consider a hypothetical support-ticket dashboard where the sales team and the support team have each customized its screens. Their page backgrounds use #F7F9FC and #F4F8FC, primary actions use #206891 and #17618B, and supporting labels use #596B7E and #566779. A HEX code specifies a web color using hexadecimal notation.
In this example, department membership is not a sufficient reason for the same action or supporting label to have a different color, so those uses can be consolidated. However, “Ticket resolved” and “Input error” mean different things and should remain identifiable. The following table shows the proposed roles and colors after the cleanup.
| Color role | Chosen color and HEX code | Reason to merge or retain |
|---|---|---|
| Page background | #F6F8FB | Consolidate the pale page colors used by separate teams |
| Ticket cards | #FFFFFF | One shared surface for list and detail views |
| Main text and headings | #26384B | Use the same text color for the same level of information |
| Supporting text | #566779 | Use consistently for dates and staff notes |
| Primary action | #17618B | “Assign to me” button and underlined text links |
| Essential borders | #738699 | Outlines needed to identify inputs and cards |
| Success notification | #E9F6EF / #176446 | Keep a paired background and text color |
| Error notification | #FDEDED / #A12634 | Keep its distinct meaning and paired colors |
On a white #FFFFFF card, main text #26384B has a contrast ratio of approximately 12.00:1, and supporting text #566779 has approximately 5.81:1. The primary button uses blue #17618B behind white #FFFFFF text for approximately 6.73:1. Text links on the same white card can use the blue with an underline, so they are recognizable as links without relying only on color.
The pale page background #F6F8FB and white card #FFFFFF have a ratio of only approximately 1.06:1. Do not rely on that slight difference alone for a necessary boundary. A visible outline in #738699 has approximately 3.75:1 contrast against white and 3.53:1 against the pale page background, making it a possible choice for inputs or cards whose outlines must be identifiable.
For a confirmed success message, deep green #176446 on pale green #E9F6EF produces approximately 6.41:1. For an error message, deep red #A12634 on pale red #FDEDED produces approximately 6.51:1. Include explicit labels such as “Resolved” or “Error” as well. Replacing both states with the primary blue just to minimize the number of colors could obscure their distinct meanings.
Review the purpose and impact before adding a new color
Whenever someone proposes another color, ask whether an existing value can do the same job, whether its contrast has been checked against the actual text, surfaces, and borders, and whether the new role will be reused elsewhere. A temporary event accent, for example, does not necessarily justify another permanent primary-button color. Keep exceptions limited to a clear purpose and duration.
Before consolidating, check where the old colors are used. Dark panels, selected rows, and fixed mobile buttons may use similar values in very different surroundings. Test the revised palette on representative screens; if a single shared color fails in one setting, reconsider the roles rather than applying the same replacement everywhere.
Under WCAG (Web Content Accessibility Guidelines) 2.2 Level AA, normal text requires a contrast ratio of at least 4.5:1 against its background, and qualifying large text at least 3:1. Necessary non-text information, including some interface outlines, may require at least 3:1 against adjacent colors. The ratios here are calculated for opaque solid-color pairs and do not establish conformance for the entire page.
HueRoll allows you to enter HEX codes, explore tints and shades, and compare a selected color with white or black. It does not directly compare arbitrary custom color pairs or automatically determine AA or AAA conformance. After consolidating your palette, verify the actual adjacent-color combinations separately.