The Problem
Alchemy's fledgling Figma library was incomplete and off-brand, the website felt dated, and no clear path existed for designers to contribute. Leadership asked me to fill that gap as the first dedicated designer on an eight-engineer team.
Beneath the surface, the problems ran deeper. Tokens existed in name but not in structure—values were stored as variables yet the set was rigid, hard to reason about, and inconsistent between design files and code. Color usage drifted across products, light/dark parity required manual fixes, and design-to-code handoff often depended on interpretation rather than a shared model. In a large organization, that drift compounds: every new surface became another chance for divergence.
My Mandate
- Rebuild the Figma design-system library from the ground up—including a new token architecture and color foundation.
- Define the Alchemy brand (logo, voice, visual language) and refresh the marketing site.
- Create a contribution and onboarding model that scales to dozens of designers.
What I Actually Found
Library debt
Core components were detached, inconsistent, and mis-aligned with Alchemy's product vision. Tokens behaved like isolated definitions rather than a coherent system teams could extend with confidence.
Underestimated scope
Branding and website work required foundational strategy—identity, audience, messaging—not just pixels. The component library had matured into a platform used by dozens of teams, but the underlying color foundation wasn't built for the variability of a large, decentralized product ecosystem.
Collaboration hurdles
Designers across five product spaces had different workflows and skill levels. Builders could find individual values, but not the decision model: which tokens were foundational vs. contextual, how values should be composed, or where to introduce new ones safely. That uncertainty created review churn and slowed delivery.
Strategy & Execution
| Pillar | Key Moves |
|---|---|
| Token Architecture | Re-built the full token taxonomy using a progressive hierarchy. Introduced a durable vs. adaptable model and implemented all variables directly into Figma Libraries to establish parity with code. |
| Color System | Proposed and built a new palette model—system colors + audience-specific accent families—with full light/dark equivalents. Used Leonardo Color for contrast-grounded ramps, then tuned values against real component pairings. |
| Design-System Rebuild | Re-architected the library with atomic components, tokens, and naming conventions. Paired with a Junior Designer; codified learnings into a public "Design-System Guide." |
| Brand & Website | Led discovery workshops to define identity, audience, and messaging. Shipped a new logo, theme, and quick-win visual updates that earned rave reviews. |
| Contribution Model | Standardized Figma Branches as a federated workflow. Authored a step-by-step contribution guide and mentored the first successful branch (Topbar component) into the global library. |
Token Architecture
During our 2023 planning cycle, we made a deliberate decision to pause expansion and invest in foundation work. Tokens were the lever—but only if they carried structure. The goal wasn't "more tokens." It was a shared, enforceable model that could translate design intent into code reliably, support multiple themes, and stay maintainable over time.
Design Principles
Predictability over exhaustiveness
A selective set of primitives rather than attempting to encode every possible scenario.
Flexibility without ambiguity
Tokens communicate intent clearly while supporting multiple themes and contexts.
Parity across design and code
The same structure, language, and hierarchy had to exist in both environments.
Progressive Taxonomy
A fully semantic-only model would have been too brittle for our scale—products varied widely by audience, workflow complexity, device constraints, and interaction needs. Instead, we adopted a progressive taxonomy that moves from general to specific, so teams can share foundations while still expressing local intent where it matters.
Token structure moves from generic foundations to specific contextual usage, enabling durable theming and system flexibility.
This structure supports consistent theming and predictable composition while reducing taxonomy debates: teams can see where a value belongs, how it inherits, and what to change without breaking downstream usage.
What Changed
The biggest shift was removing interpretation from handoff. With a shared hierarchy between design and code, implementation questions moved from "what does this map to?" to "is this the right decision for the context?" Teams gained a safer path to extend the system—clearer naming, predictable inheritance, and an explicit place for theme and state. That reduced review churn, improved parity, and made it easier to support multiple experiences without fragmenting the foundations.
Color System
Before accelerating component and pattern delivery, we needed to rebuild the primitives everything depends on—starting with color. The goal wasn't a new aesthetic. It was a model that encodes intent: predictable relationships, clear semantics, and durable behavior across themes and modes.
Two Palette Types, One Clear Job Each
System Colors
A neutral palette (white, gray, black) plus alert colors (success, warning, error) that remain stable across themes to preserve familiarity and predictable behavior.
Accent Colors
Curated hue ramps used to communicate interactivity, reinforce hierarchy, and enable theme or audience differentiation.
Audience-specific accents were a deliberate decision: Blue was retained for Operator experiences to preserve continuity; Purple was introduced for Associate themes to clearly differentiate the experience while keeping the overall UI calm and usable. Every palette was built with equivalent light and dark values so visual relationships remain intact when modes switch.
Durable vs. Adaptable Tokens
To avoid a one-size-fits-all system—or a fully local free-for-all—semantic color tokens were grouped into two sets:
Durable
Preserve familiarity across themes: shared surfaces, default text, baseline borders, and predictable states. Surface tokens were intentionally durable—keeping surface relationships consistent preserves elevation clarity, especially in dark mode where shadows are unreliable.
Adaptable
Allow controlled variance for audience needs: brand expression, navigation emphasis, and primary actions. This creates a clear contract for what stays consistent versus what can vary.
Contrast as a System Constraint
Contrast was treated as a system constraint, not a last-mile check. Palettes were initially generated with Leonardo Color to establish accessible relationships, then tuned against real component pairings—balancing mathematical correctness with practical usability.
Teams still validate custom compositions, but the system now does most of the work up front.
Color Palette
Outcomes
- Refreshed foundations supporting Operator and Associate themes across Figma and code
- Modern token architecture enabling scalable theming beyond color
- Clearer alignment between design intent and engineering primitives
- Beta pilots with 3 customer teams validating the direction
- Improved documentation to reduce adoption friction
- Performance and maintainability gains through simplified foundations
- Foundation that later supported Common Experience work across teams without a shared front-end stack
Key Takeaway
By pairing evidence-driven interviews with a rigorous governance model, I transformed a fragmented UI landscape into a scalable system that boosted accessibility by 32 points and cut engineering effort by nearly a quarter—all while up-skilling the team and aligning executives on a single, measurable vision of product quality.
For me, this was a clear reminder that scaling UI isn't primarily a visual problem—it's a clarity problem. A well-structured token model becomes shared language: it reduces ambiguity, improves collaboration, and gives teams a durable way to ship consistent experiences at speed.
| KPI | Before | After | Delta |
|---|---|---|---|
| Accessibility score (axe-core) | 65% | 97% | +32 pp |
| Average feature build time | 5.1 days | 3.9 days | −24% |
| Duplicate CSS/JS per app | 14k lines | 4k lines | −71% |
| Designer onboarding time | 2 weeks | 3 days | −78% |
These KPIs reflect progress toward my north-star goal: building a scalable, accessible design system that improved usability and team efficiency.
What's Next
- Automate component health reporting to track adoption and debt.
- Continue refining the contribution flow as more teams onboard.
- Note: Due to organizational changes, the final stages of the refresh were deprioritized in Q1 2024. Alchemy continued supporting prior versions while focusing on data visualization and complex table needs. Ownership was later moved to another AFT team.
Return to Home