Scaling an enterprise design system from tool to product
To evolve Vanguard's design system I implemented a new operating model that allowed us to work faster, tackle bigger challenges, and enabled designers and engineers across the org to deliver more consistent and usable experiences.
New internal processes
I built structure for our component delivery process by introducing a new model for communication, review, collaboration, and co-authoring.
Solving problems for adopters
I sped up the intake and delivery of new component and pattern requests to build trust, deliver value, and collaborate with our adopters.
Bridging design & engineering
Through frequent touchpoints and working sessions, we built new specification templates, taxonomy standards, API structure, and a culture of partnership.
Our 1.0 library was an MVP; a handful of foundational components, basic styles, and ad-hoc processes. We struggled to tackle complex components or handle conflicting input from feature teams.
As a team we identified these goals for 2.0; scale the library, ensure consistent quality, close the design/dev gap, build the right features and components, and properly support the teams that needed them.
New components started with a proposal template capturing use cases, accessibility constraints, business value, and visual references, all co-owned by designers, engineers, and product partners.
With requirements locked early, designers ran async check-ins and structured reviews. The proposal became the source of constraints, so the team moved faster inside clear boundaries.
Spec sheets became the shared artifact between design and engineering, documenting states, properties, interactions, and tokens against a common API taxonomy.
Internal mentorship
Async check-ins and structured reviews replaced standing meetings, enabling smaller groups to collaborate and upskill.
Cross-team workshops
By partnering with our feature teams to gather requirements, understand constraints, and define use cases, we could build solutions based on real needs.
Bringing in industry experts
We worked with Nathan Curtis to develop our new spec template, which he later adapted into the now-popular Specs plugin.
Components shipped ready to adopt
Each finalized component shipped with a working spec, anatomy breakdown, and accessibility notes, so engineers could implement without back-and-forth, and downstream designers could trust the source.
Easy-to-read documentation
I wrote the guidelines and markdown templates for our new documentation site, with sections for examples, properties, and usage guidance, visuals for the various configurations, and clearly flagged content limitations and accessibility considerations.
Patterns that compound across teams
Beyond individual components, we documented recurring patterns (composition rules, layout primitives, and content guidelines) so new product surfaces could assemble cohesive experiences without starting from zero.
growth in design-system adoption across product surfaces over two quarters. The system went from a nice-to-have to a tool teams reached for by default.
What I carry forward
The real product was never the component library; it was the operating model around it. Investing in how the team proposed, specced, and shipped compounded across every surface, and turned adoption into a design outcome rather than a mandate.