Design Systems · Architecture

Building a Scalable Token System

Building a scalable token system from the ground up — defining semantic layers, multi-brand theming, and a governance model that enables enterprise design systems to scale with confidence.

← Back to Work

Project Context

As a lead UX design contractor at Fidelity Investments, I spearheaded the creation of a centralized design system from the ground up to support the enterprise-wide migration to a new shared technology platform, HarmonIX. My scope of work encompassed architecting the foundational system in both Figma and code, while partnering directly with independent design and engineering teams to drive adoption and ensure seamless, consistent application reuse.

What Needed to Change

Prior to the HarmonIX platform, fragmented development teams were independently building and maintaining similar applications. This siloed approach led to redundant development efforts and inflated technical costs. For the end-users, navigating these disparate applications meant dealing with inconsistent interfaces and unpredictable UI behaviors. This lack of standardization created a steep learning curve, necessitating expensive and time-consuming training sessions just to teach users how to operate each team's specific app.

The absence of a shared design language drove up development costs through redundant work and created a fragmented, high-friction user experience that required extensive, costly training to navigate.

Working Within Boundaries

Technical

Due to a tight project timeline, building custom components from scratch was not viable. We evaluated third-party libraries and integrated PrimeNG as our foundational framework. This required the HarmonIX Design System (HDS)—including all design tokens and Figma components—to be strictly architected to conform to PrimeNG’s specific structural methodologies and technical parameters.

Business

We operated under an aggressive three-month timeline to launch a "usable" MVP of the HarmonIX Design System (HDS). This required us to strictly scope our initial release to only mission-critical components, such as buttons, modals, and form controls. Additionally, business requirements mandated that HDS include specific patterns to support teams porting over legacy application functionality, all while maintaining strict WCAG accessibility compliance

User

Designing for investment professionals required highly data-dense, spreadsheet-like interfaces optimized for intensive daily use. These web-based applications were rendered within a native desktop wrapper, introducing specific environmental constraints. We also had to manage deep-rooted cognitive constraints by retaining specific legacy color associations, establishing a strict shared lexicon (such as exact decimal formatting for currencies versus percentages), and supporting complex localization for a joint US and European user base.

Design

We leveraged Fidelity’s external consumer design system (FDS) as a baseline, adopting foundational elements like the Fidelity Sans typeface, a 4px spacing grid, and existing iconography. However, because FDS was optimized for retail consumers rather than specialized investment professionals, we had to intentionally diverge from its guidelines—customizing data density, typography scales, and primary colors to suit our users. Ultimately, the visual and interaction design was heavily bound by the PrimeNG framework, requiring us to constantly balance Fidelity's brand standards against the structural trade-offs of the component library.

Approach & Timeline

[Outline how the project was structured. What phases did it move through? Who were the key collaborators?]

  • Initiated outreach across 10 Asset Management design teams to conduct a surface-level application audit. We established a centralized Figma repository, structured by component category, where designers contributed real-world application screenshots to identify shared patterns—proving especially valuable for complex UI constructs. Simultaneously, we defined a collaborative contribution model to scale our small core team's output and established weekly cross-functional office hours to maintain alignment and iterate on feedback with both designers and developers.
  • [Phase 2 — e.g., Discovery & user research]
  • [Phase 3 — e.g., Ideation & wireframing]
  • [Phase 4 — e.g., High-fidelity design & iteration]
  • [Phase 5 — e.g., Handoff & implementation support]

Understanding the Space

[Describe the methods you used — interviews, usability tests, competitive analysis, surveys, data review, etc.]

[Who did you talk to? What were you trying to learn? How did research shape your understanding of the problem?]

What We Learned

Finding 01

[Describe a key insight from research and its implication for the design.]

Finding 02

[Describe a key insight from research and its implication for the design.]

Finding 03

[Describe a key insight from research and its implication for the design.]

Results & Impact

—
[Metric label]
—
[Metric label]
—
[Metric label]

[Summarize what was delivered, what impact it had, and any qualitative or quantitative outcomes you can share.]