(using computed hue, saturation, luminance — NOT guessing)
| Color Family | Count | % | Interpretation |
|---|---|---|---|
| 🔵 Blues | 250 | 29.6% | Overuse → CTAs, info badges, legacy links, graphs |
| ⚪ Greyscale | 199 | 23.5% | Surfaces, text, borders → MUST be compressed |
| 🟧 Orange / Yellow | 120 | 14.2% | Alerts, warning states, campaign UI |
| 🟢 Greens | 113 | 13.3% | Success, WhatsApp-tinted UI, verification |
| 🔴 Reds | 102 | 12.1% | Errors, delete buttons, banners |
| 🟣 Purple | 35 | 4.1% | Possibly noise, charts, campaign themes |
| 💗 Pink | 14 | 1.6% | Rare, likely branding/campaign leftovers |
| 🟡 Yellow-Green | 12 | 1.4% | Unclear usage, possible mixed-tone badges |
Step-1 → building Source of truth
→ contains
every raw color
in the codebase
→ normalized into
(r,g,b,alpha,raw)
format
Step-2 → Master Genome File
Goal:
Unify all colors in the codebase into one safe canonical representation, BEFORE tokenizing / replacing.
What we Must Do First
Before touching tokens, clustering, or mapping —
We must refactor all CSS to a consistent standard encoding, so that:
#fff, white, rgb(255,255,255)#1b74e31f, rgba(27,116,227,0.1)% opacity or random shorthandMaster Genome File
What’s Inside (Columns Explained)
| column | meaning |
|---|---|
raw |
exact original value from your extracted list (including trash, typos, rgba, 3-digit hex etc.) |
canonical |
normalized rgba(r,g,b,a) — your final target encoding |
alpha_type |
scrim, overlay, mask, semi, full, or invalid |
score |
0-100 → “auto-replace confidence” |
bucket |
coarse color family (grey, green, blue, red/orange, other) |
replace_safe |
YES, NO, NEED_REVIEW |
notes |
metadata space (currently blank, can later contain “shadow-only”, “platform-color”, etc.) |
Color Tokenization Stage 1 (HEX-Only) — Completed Summary
We wrapped hardcoded hex colors behind a token layer — no UI change, zero risk.
We completed the first foundational phase of color modernization — extracting and wrapping hardcoded hex colors across the app, introducing a stable, zero-risk token layer that makes future UI changes possible without breaking production.
Before this work:
This work removes UI debt that would otherwise compound over time.
We introduced a translation layer to wrap hex values, without changing visuals:
--wati-raw-353735: #353735;
--wati-raw-666666: #666666;
--wati-raw-d1d1d1: #d1d1d1;
Usage example:
color: var(--wati-raw-666666)
border: 1px solid var(--wati-raw-d1d1d1)
This makes the UI refactor-safe while remaining pixel-perfect.
| Action | Output |
|---|---|
| Extracted raw hex values across repo | CSV inventory |
| Validated replacements | Cursor preview screen |
| Applied updates | 15 files modified |
| Visual output change | 0% (no diff) |
To avoid production risk:
Rollback is instant → delete the CSS import & remove override file.
| --- | --- |
⚠️ Low % by design — Stage 1 = infrastructure, not completion.
| --- | --- |
This foundation unlocks:
This document is the full narrative of how we began transforming Wati’s UI foundation from a fragmented legacy color codebase into a modern, scalable design system — using human-led rules, AI-assisted refactoring (Cursor), and safe staged rollout methodology.
Prior to this migration, WATI’s interface was held together by:
#666, #353735, rgb(0 0 0 / 40%), rgba(0,0,0,0.12), and named colors like tomato