Auditing a Color System: A Practitioner's Checklist

Color system audits are underused and undervalued in design practice. Most color systems are built incrementally — a color added here for a new feature, an exception made for a campaign, a temporary fix that became permanent. Over 2-3 years, what started as a coherent system accumulates entropy. A systematic audit every 12-18 months catches and corrects this drift before it becomes expensive to fix. **Inventory: What Colors Actually Exist** The first step is documentation: every color value that appears anywhere in the product, design system, or marketing materials. This is often alarming in its results. It is common to discover 40-60 distinct values in use, often with near-duplicate values that were created because the correct value could not be found quickly. The inventory can be built from design tool inspection (extract all unique fills, strokes, and text colors), from CSS analysis (grep for color values in stylesheets), and from design token files. The output is a complete, unfiltered list. **Consolidation: Identify Drift** From the inventory, identify clusters of similar values that represent the same semantic role. Near-duplicate grays (4 slightly different text grays where 2 was intended) are the most common finding. Accent color drift — where the brand blue has drifted to 3-4 nearby hex values across different components — is the second most common. For each cluster, determine the intended canonical value and document the deviations. **Accessibility Audit** For each text color / background color combination that appears in the product, compute the WCAG contrast ratio and compare to the target level (AA minimum: 4.5:1 for normal text, 3:1 for large text). Automated tools (axe, WAVE, Storybook a11y addon) catch most cases but require manual review for complex UI. Document every failing combination with the current ratio, the target ratio, and the recommended fix (usually a slight darkening of the text color or lightening of the background). **Token Review** If the color system uses design tokens, review whether the token structure still maps well to current usage. Primitive tokens (the raw color values) should be stable and limited. Semantic tokens (the meaning layer: --color-text-primary, --color-surface-default) should cover every actual use case in the product. Component tokens (--button-background-hover) should reference semantic tokens, never primitives. Any component token referencing a primitive directly is a sign of semantic token gaps. The goal of a token audit is a clean two-layer hierarchy with no bypasses.