EVDS: a 4-layer token system that turned 12 disconnected products into one design language.
How I led the design and architecture of the EdgeVerve Design System (EVDS) — from a static Adobe XD library to a token-driven, three-theme system now adopted as the default for new work across EdgeVerve's AI product suite.
Twelve products, twelve design languages, one Adobe XD file that couldn't keep up.
EdgeVerve's AI product suite — 12 surfaces spanning Home, Value Cockpit, Conversation AI, Value Discovery, Digital Worker, Document AI, Engage, Harness, Harmony, Neural Connect, Business Apps, and Studio — grew out of separate teams designing in isolation, mostly in Adobe XD. XD had no real token or variable support, so every "shared" pattern was really just a copy-pasted frame that quietly drifted the moment someone touched it.
No single source of truth
The same button existed as dozens of near-identical XD frames, each editable independently — so "fixing" one never fixed the rest.
Tooling ceiling
XD couldn't support variables or true component variants, which meant theming or scaling to a second brand was structurally not possible without a rebuild.
Inconsistent data visualization
Dashboards across the twelve products used different chart colors and states, so the same kind of data looked like it belonged to different products.
No shared vocabulary
Designers described the same decisions differently across teams, which made design reviews slower and handoff to engineering inconsistent.
Four layers, not one flat palette.
I structured EVDS as a strict four-layer hierarchy in Figma Variables — the separation of "what" and "how" that lets a system like Material span very different products without a rebuild per surface.
Two separate cascades below — color and sizing resolve independently, through different alias tokens, before they ever reach a component.
Primitive
Colour collectionSemantic
Tokens collectionComponent
Button instanceSizing cascade — Number Scale → Spacing alias → component padding
Same components. Three themes. Zero rebuilding.
Purple, Blue (the default light theme), and Dark all live as three modes inside the same Tokens collection — the semantic slot names never change, only the value each theme resolves to.
Pending review
4 flagged items
Designer-level customization, not a request queue.
Every core component ships with a properties panel — style, size, state, and content toggles a designer configures directly on the instance, mirroring the real Button component in EVDS.
Contrast was a token constraint, not a QA checklist.
I led EdgeVerve's separate WCAG 2.2 AA compliance initiative, and folded that discipline directly into EVDS's semantic layer rather than treating accessibility as a review step after design.
Contrast-checked at the token level
Every semantic text/background pairing (e.g. color-text-default on color-bg-base) was verified against WCAG 2.2 AA before being made available to components — keeping approved token pairings compliant by default.
Dark mode required its own pass
Reusing light-mode hues at the same saturation on a dark surface broke contrast — the dark-mode value set for accent and status colors was independently checked and adjusted, not auto-inverted.
Semantic status colors, not just decoration
Success, Warning, Error, and Critical tokens carry both a color and a required icon pairing in components, so status is never communicated by color alone — a WCAG requirement.
Data-viz built for color-vision deficiency
The 14-step tonal scales give charts enough luminance separation to stay legible without relying purely on hue — important given how color-dense the Control Tower and Analytics dashboards are.
A system stays alive by how it's maintained, not how it launched.
EVDS ships as a numbered release with a public changelog (currently v4.1.1), not a Figma file people quietly edit. That structure is what let it survive three major phases without fragmenting again.
- CONTRIBUTION New components or variants go through a review before merging into the library — designers propose, I (and now the wider team) review against the existing token set before anything ships as reusable.
- VERSIONING Every release is numbered and changelogged (v4.0.5 → v4.1.0 → v4.1.1), so engineering always knows exactly what changed and why, instead of silently inheriting edits.
- DOCUMENTATION Every component page carries a "Ready for dev" status flag and usage notes directly in Figma — not a separate wiki that goes stale.
- SYNC Tokens are the handoff artifact engineering consumes directly, closing the Figma-to-code gap that existed constantly back when everything lived in Adobe XD.
- ADOPTION Migration & Enablement: Led weekly office hours, component deprecation audits, and hands-on variable migration workshops for the 6-person design team to transition legacy Adobe XD layouts into strict tokenized Figma instances without halting active feature delivery.
Token edits published in Figma automatically trigger a Style Dictionary build pipeline, outputting themed CSS custom properties consumed directly by React components.
47+ documented components and modules.
Core Components 13
Feedback & Status 8
Navigation & Layout 10
Data & Patterns 16
From a static Adobe XD file to a living, token-based system.
XD to Figma migration
- Migrated EVDS from Adobe XD to Figma — the foundation everything after this depended on, since XD had no path to variables or true theming.
Properties-panel configuration
- Designers configure components entirely through the properties panel — no more manual edits inside instances.
- Editable text labels, instance-swap icon customization, and flexible style/state/size controls added directly to components.
- Boolean controls and dynamic subcomponents (e.g. configurable tab count) introduced.
- Variants added across all EVDS pages; variables wired into component creation for future-proof editing.
Design tokens & theming
- Adopted Inter as the system typeface for consistency across platforms.
- Introduced the four-layer token architecture shown above, for scalable theming and easier updates.
- Shipped Light and Dark mode via token-based theming, with Purple and Blue as variants in the same collection.
What changed in how the team actually works.
Reduced new screen assembly time by an estimated ~40% by eliminating blank-frame recreation across all 12 product lines.
Reached an estimated ~100% component adoption for new feature builds across the 6-person UX team within roughly 8 weeks of the v4.1.0 rollout.
Cut new theme implementation time from weeks of manual UI overrides to an estimated ~2 days via semantic token remapping.
Achieved ~100% automated WCAG 2.2 AA contrast coverage for core component tokens, with QA-reported visual contrast bugs dropping close to zero.
What made this a system change, not just a system.
"The alias layer is the part nobody sees and everybody benefits from. Once spacing, radius, and type size all trace back to one Number Scale, theming stops being a redesign — it's just a different set of values plugged into the same slots."
Three production themes weren't a Figma trick — they came from refusing to let any component reference a raw value, and from accepting that dark mode needed its own contrast pass rather than a free inversion. The harder work was less about tokens and more about getting a 6-person team to stop reaching for a new frame every time a screen felt slightly different.