Color Déjà Vu: How Design Teams Keep Accidentally Inventing Colors They Already Own

Somewhere in your codebase right now, there's a #2B4A8F sitting three lines away from a #2C4B90. They look identical on screen. They're supposed to be the same color. Nobody knows which one is "official," and honestly, nobody remembers where either of them came from.

Welcome to the hex code graveyard — a very real, very common problem that plagues design teams of every size. It's not a small inefficiency. It's a slow bleed that costs hours, inflates stylesheets, and quietly erodes the visual consistency your brand depends on.

Let's talk about why this keeps happening and, more importantly, how to stop it.

Why Teams Keep Reinventing Colors They Already Have

The short answer: because finding an existing color is harder than it should be.

Design systems are supposed to solve this. You publish a Figma library, drop your hex codes into a shared Notion doc, maybe build out a proper token system if you're feeling ambitious. And then someone on the team needs a slightly muted version of your primary blue for a new component. They can't find the right token name. The Figma library hasn't been updated since Q1. So they eyeball it, grab a hex code from a screenshot, and move on.

That new hex code gets committed. Nobody flags it in review. Six months later, your stylesheet has four variations of the same blue, and your junior dev is asking which one to use in the new onboarding flow.

This isn't a discipline problem — it's a systems problem. Color duplication happens when the path of least resistance is creating rather than finding.

The Real Cost of Duplicate Hex Codes

Duplicate colors aren't just a philosophical annoyance. They have real consequences.

Bloated CSS. Every near-duplicate that sneaks into your stylesheet is dead weight. Over time, this adds up — especially in large codebases where multiple teams are committing styles independently.

Inconsistent UI. Users notice when buttons in one section of your app are a slightly different shade than buttons elsewhere. They might not consciously think "those hex codes are different," but they feel it. It creates a subtle sense of something being off, and that erodes trust.

Rebrand chaos. When it's time to update your brand colors, you have to hunt down every variant. If you've got #E63946 living alongside #E53A45 and #E73947 in different parts of your codebase, a find-and-replace won't catch everything. Manual cleanup is painful and error-prone.

Designer time wasted. Hours spent recreating colors that exist, debating which shade is "right," and auditing old files for the canonical value — that's time that could go toward actual design work.

How to Actually Audit Your Color Library

Before you can fix the problem, you need to know how bad it is. Here's a practical framework for running a color audit that doesn't take forever.

Step 1: Extract Every Hex Code in Your Codebase

Run a grep or regex search across your CSS, SCSS, or Tailwind config files for hex patterns (#[0-9A-Fa-f]{3,6}). Tools like grep -roh '#[0-9A-Fa-f]\{3,6\}' on a Unix system will dump every hex value in your project. Export that list.

For design files, most modern tools have plugins that can extract all color values from a Figma or Sketch file. Use them.

Step 2: Cluster Similar Colors

This is where it gets interesting. Don't just look for exact duplicates — look for near-duplicates. Colors within 5-10 units of each other in HSL space are usually candidates for consolidation.

You can use free tools like ColorSlurp, Coolors, or even a quick script using a color difference algorithm (Delta E is a good one) to group colors that are visually indistinguishable.

Step 3: Map Back to Your Design System

For each cluster of similar colors, ask: which one is the canonical value from our brand guidelines? If you can't answer that question, that's a red flag — your design system documentation isn't clear enough.

Create a mapping table: unofficial hex → official token. This becomes your cleanup roadmap.

Step 4: Eliminate and Consolidate

Swap out unofficial hex codes for design tokens or CSS custom properties. Something like var(--color-primary-blue) is a lot harder to accidentally duplicate than a raw hex string, because it points to a single source of truth.

If you're using a token-based system, this is the moment to enforce it. If you're not, this audit is a great reason to start.

Building a System That Prevents the Problem

Auding is reactive. What you really want is a setup that makes color duplication difficult in the first place.

Use design tokens everywhere. Tokens with clear, semantic names (color-brand-primary, color-feedback-error) are much easier to find and reuse than a bare hex code. When developers know the token name, they don't need to guess the hex.

Keep one source of truth. Whether that's a Figma library, a tokens.json file, or a Storybook instance, your color definitions should live in exactly one place. Everything else references that place. Full stop.

Lint for raw hex codes. Tools like Stylelint can be configured to warn or error when raw hex values appear outside of your token definitions. If someone tries to commit #2C4B90 directly into a component stylesheet, the linter catches it before it merges.

Make the right thing easy. If finding a color token requires digging through a stale Confluence page, people won't do it. Put your palette somewhere obvious — a pinned Figma file, a design system site, a VS Code extension. Reduce the friction of doing things correctly.

The Conversation Your Team Needs to Have

Here's the uncomfortable truth: color duplication is often a communication failure as much as a tooling failure. Designers and developers are working in parallel, sometimes without clear handoff protocols. A designer picks a color in Figma that looks right. A developer implements it by eyeballing the comp and entering a hex code manually. Those two values are close — but not the same.

Solving this means creating explicit agreements about where colors come from and how they get implemented. It means developers pulling from token files, not color pickers. It means designers keeping their libraries updated. It means someone owning the design system and treating it like a living product, not a one-time deliverable.

None of that is glamorous work. But it's what separates teams whose brand looks polished and consistent from teams whose UI quietly drifts into chaos over time.

Start Small, Start Now

You don't need to overhaul your entire system this week. Start with the audit. Run the grep. Export the hex list. Spend an afternoon clustering near-duplicates and mapping them back to your official palette.

You'll probably find more ghosts in that graveyard than you expected. And once you can see the full picture, cleaning it up becomes a lot more manageable — one canonical hex code at a time.