Building AXS: Platform Creation and Enterprise Standardization

Context

Front-end at FAS was fragmented across apps, marketing sites, and content platforms. Teams were building inconsistent UI components. Designers and developers lacked a shared source of truth. Delivery speed was bottlenecked by rework, misalignment, and redundant implementations.

The need was obvious: a unified, scalable front-end system. The hard part was the cross-team alignment, the funding, and the sustained adoption work it would take to actually get there.

My role

I was a foundational leader in defining, building, and scaling AXS. Not just a contributor, I helped turn it into a platform with ownership, governance, and an adoption strategy. I co-authored the vision narrative, established front-end as a shared service model, and bridged engineering, UX, and business stakeholders.

What I did

Defined and evangelized the vision. AXS as a unified design system for FAS, framed as a business enabler, not a developer tool. The narrative explicitly positioned the system as a way to deliver consistent, on-brand experiences across product, marketing, and content.

Built a scalable, multi-framework component system. Centralized component library serving AEM (~40 components), Angular (~30 apps/components), and Vue (~35 apps/components). Designed code- and framework-agnostic from day one so the system would scale across whichever stack a team needed.

Created a cross-functional operating model. AXS as a shared service owned by FED and UX together. Continuous collaboration between design and development. Marketing enabled, not blocked, direct access to the same components engineering uses.

Established developer experience and adoption channels. Storybook as the single source of truth, integrated with Figma. Developer workflows and onboarding wired to the same documentation surface. One mental model for designers, engineers, and marketers.

Enforced governance. Rejected proposals that would introduce externally-owned components or split ownership models. Mixed ownership fragments delivery and creates dependencies, I held that line consistently. AXS remained a cohesive, centrally-governed system, and adoption aligned to one standard.

Resistance

Fragmentation pressure. Teams wanted custom components, partial ownership, integration of external systems. Allowing it would have killed the platform within a year.

Cross-team misalignment. Other teams operated at different speeds with different priorities. There was pressure to merge systems prematurely or adopt inconsistent practices.

Behavior change. Teams had to shift from building locally to using shared components, from autonomy to platform alignment.

How I handled it

Positioned AXS as a business enabler, not a component library. Combined flexibility (multiple frameworks supported) with control (central ownership, strict governance). Led with clarity and consistency: same answer to the same question every time, so the platform’s direction was never ambiguous.

Outcome

• Enterprise-scale adoption. Used across 300+ pages on advisors.vanguard.com and multiple frameworks.
• Standardized front-end development. Single system for components, design patterns, and UI consistency.
• Accelerated delivery. Teams reuse components, build faster with less rework, deliver consistent experiences.
• Business users enabled. Through the AEM integration that followed (Chapter 4), marketers and content creators leverage AXS directly.
• Platform foundation. AXS is no longer just a design system; it’s a front-end platform layer that supports multi-framework apps, CMS integrations, and the AI work that came later.

Why it matters

This is a step-function change in what front-end is at FAS. The transformation:

• From components → to ecosystem.
• From developer tool → to enterprise capability.

The work demonstrates platform ownership, cross-functional leadership, enterprise-scale impact, and the alignment of business and engineering toward a single shared system.