Case study 02 · 2026
Role — Product design, system design
Product — Enterprise Admin platform
Scope — tokens, Components, templates
Why this, why now
Design system as AI infrastructure
Token cleanup, component consistency, margin rules — this is foundational design system work that needed doing with or without AI. What changed is the priority. As our team started shipping features through AI-assisted implementation, the cost of ambiguity went up: a model can't infer an unwritten rule the way a teammate might.
I mapped this out as a four-phase roadmap — Constraints, Context, Verification, Feedback — treating the design system less as a style guide and more as the shared context an AI-assisted workflow depends on. Most of the conversation around "context engineering" for AI development comes from the engineering side: codebases, docs, sub-agents. This is the same problem approached from design — making sure the intent behind a screen is legible to a model, not just to a human reviewer.
This case study covers phase one: Constraints.
Context
An enterprise Admin panel had grown to roughly 100 pages without a shared foundation. As tooling made it clearer that teams need to produce consistent pages quickly regardless of who built them, I identified the Admin panel as a strong candidate for reusable, AI-assisted templates.
The problem
52 untracked shades of gray made the interface feel like it had no rules.
A Claude Code audit surfaced 52 undefined gray values in the codebase. Existing Storybook components applied tokens automatically, but new components often copied raw values from Figma. Because Admin pages were rarely compared side by side, small inconsistencies stayed invisible — while design and engineering absorbed the communication cost.
Why we replaced the Admin color palette
Admin did have a color palette. What it did not have was a system.
The palette defined primary, positive and negative states, and eleven grays — enough for the screens that existed when it was written. Two things followed:
Gray coverage was insufficient. No value existed in the range secondary text requires, so contributors introduced their own, in place.
The palette lived in the design library, not in code.
Even correctly defined entries sometimes had no counterpart in_theme.scss— I found three cases where the mapping was simply missing, so there was nothing to reference even when someone wanted to.
The result was 52 hardcoded hex values outside the theme file — not because a palette was missing, but because the one that existed was incomplete on one side and unenforceable on the other.
1. The distribution is collapsed
Seven of the eleven grays sit between #E2E6EA and #F8F9FA — roughly the lightest 8% of the range. Meanwhile there is no token at all between #595959 and #A0A9B5, which is exactly where secondary body text needs to live.
Admin's gray text has never met contrast requirements because a compliant value did not exist in the palette. This is not an oversight in usage; it is a gap in the palette itself.
2. The numbers don't track lightness
Gray 40 is lighter than Gray 50. Gray 70 is lighter than Gray 80. The scale cannot be reasoned about — choosing "one step darker" requires looking up hex values rather than reading the name.
3. Near-duplicates are indistinguishable
Gray 70 #F0F2F5 and Gray 80 #EEF0F3 differ by two levels per channel. No one can tell them apart on screen, but both must be maintained, documented, and chosen between.
4. Hue is not consistent
Gray 20
#595959— fully neutral, 0% saturationGray 10
#2D2F4E— navy, ~27% saturation at 236°Gray 30–60 — blue-tinted, 13–32% saturation
Placing text on sub-text produces a visible color shift, because the two are not on the same hue.
5. Names encode usage, not value
"Text Color", "Modal Close Background", "Button Hover" — each primitive is locked to a single purpose, so every new context requires a new color. Gray 35 and Gray 38 exist because two values had to be retrofitted between Gray 30 and Gray 40. The numbering itself is a record of ad-hoc growth.
The decision
Make the cleanup visible — and make it part of the shared system.
A token assignment map alone did not create a visible product change. In response, I paired the cleanup with improvements to component color and contrast. I also migrated Admin-specific components toward the existing dashboard design system, which already met contrast requirements and aligned with a company-wide direction.
What changed
Why the whole palette, not only gray
Buttons and borders were the first fix. Coming next are colored tags, status and message colors, and other categorical UI.
We could add each hue when its feature ships. That is precisely the process that produced the 52 strays: the palette was extended reactively, one screen at a time, and only on the design side.
A palette is only useful if it is closed. Once a full set exists, "invent a new color" stops being a reasonable thing for anyone to do, and reviewers gain a rule they can actually enforce.
On the swatch count
The number of swatches went up, from roughly 24 to 80+. The relevant metric is not swatches but decisions.
Under the old palette, every color choice was an open judgment: which of these near-identical grays is correct here? Under the new one, the ramp is fixed and the only question is which step. Once semantic tokens land, implementers name an intent rather than choosing a color at all.
Open item
Dark filter #2D2F4E 80% has no counterpart in the new ramps. An overlay is an effect, not a color, and needs to be defined separately as an elevation/overlay token.
Execution
I rebuilt buttons with accessible color specifications, clarified frame borders, standardized reusable page and table patterns, and migrated component colors to Design System tokens. Figma Slots now give elements dropped into templates a consistent 32px spacing rhythm.
AI as an audit partner
Claude Code made the 52-gray audit practical. Separately, Claude analyzed 30–40 deduplicated Admin screenshots and converged on three recurring page layouts — a result I cross-checked against two years of domain experience. I added two modal templates beyond that scope, based on my own structural analysis.
Outcome
5 issues
Insufficient color contrast · before
1 issue
Insufficient color contrast · after
Under matched axe DevTools scans, total issues fell from 11 to 7 and serious issues fell from 6 to 2.
Moreover …
Improved the border contrast (checkbox and search input)ratio from 1.25:1 to 2.3:1 — still short of the WCAG 3:1 threshold, but a clear gain in visibility. Traced the root cause to the design system's defined values and, rather than applying a local fix, raised the issue with the DS team.
SUMMARY
Building a scalable design system to streamline component adoption and speed up production.
I am currently driving the adoption of new components, documenting design patterns, and advocating for consistent interactions across the product.
My goal is to enable anyone—whether human or AI—to create pages that follow clear, consistent rules, while reducing unnecessary communication and alignment overhead.