_WORK
_ ABOUT
_WORK
_ ABOUT
_WORK
_ ABOUT
_WORK
_ ABOUT

Building & maturing an enterprise-scale design system

OVERVIEW

I worked on the creation, maintenance, and maturation of a cross-platform design system for The Vanguard Group through new components, updated team processes, and documentation for the teams adopting the system.

We improved the quality & speed of delivery for components, improved hand-off efficiency with technical documentation, and increased org-wide adoption through usage documentation, socialization, and new requirement-gathering processes.

Role

Senior Designer

Duration

8 months

Responsibilities

Design systems, design strategy, component design, user experience & interaction design, technical documentation

GOALs & OBJECTIVES

For the 2.0 version of the VDS, our goals were to ship more complex components, take in requests from our adopting teams, and scale both our system and team.

VDS 1.0 was MVP-focused and delivered a small set of foundational components and styles.

By expanding our efforts to standardize components and common UX patterns, we would continue to help our adopting teams reduce design and technical debt, increase experience consistency, and deliver features faster.

For the 2.0 version of the VDS, our goals were to ship more complex components, take in requests from our adopting teams, and scale both our system and team.

VDS 1.0 was MVP-focused and delivered a small set of foundational components and styles.

By expanding our efforts to standardize components and common UX patterns, we would continue to help our adopting teams reduce design and technical debt, increase experience consistency, and deliver features faster.

For the 2.0 version of the VDS, our goals were to ship more complex components, take in requests from our adopting teams, and scale both our system and team.

VDS 1.0 was MVP-focused and delivered a small set of foundational components and styles.

By expanding our efforts to standardize components and common UX patterns, we would continue to help our adopting teams reduce design and technical debt, increase experience consistency, and deliver features faster.

For the 2.0 version of the VDS, our goals were to ship more complex components, take in requests from our adopting teams, and scale both our system and team.

VDS 1.0 was MVP-focused and delivered a small set of foundational components and styles.

By expanding our efforts to standardize components and common UX patterns, we would continue to help our adopting teams reduce design and technical debt, increase experience consistency, and deliver features faster.

REdefining our team processes

Through cross-discipline workshops & collaboration sessions, we re-defined and standardized our end-to-end process for agile component development and delivery.

The goals were to enable team collaboration and efficiencies through regular cross-discipline checkpoints, visibility into status & responsibility, and shared responsibilities.

Enabling agility and visibility

Combining this structure with standardized JIRA tickets helped us clearly scope and roadmap each sprint and fiscal quarter with well-defined requirements and definitions-of-done.

Cross-discipline alignment

By expanding the review and approval process for each phase to include every disciplines, all team-members had insight into each step, while helping define and shape the direction of the component as it got built, rather than at the end of the process.

Through cross-discipline workshops & collaboration sessions, we re-defined and standardized our end-to-end process for agile component development and delivery.

The goals were to enable team collaboration and efficiencies through regular cross-discipline checkpoints, visibility into status & responsibility, and shared responsibilities.

Enabling agility and visibility

Combining this structure with standardized JIRA tickets helped us clearly scope and roadmap each sprint and fiscal quarter with well-defined requirements and definitions-of-done.

Cross-discipline alignment

By expanding the review and approval process for each phase to include every disciplines, all team-members had insight into each step, while helping define and shape the direction of the component as it got built, rather than at the end of the process.

Through cross-discipline workshops & collaboration sessions, we re-defined and standardized our end-to-end process for agile component development and delivery.

The goals were to enable team collaboration and efficiencies through regular cross-discipline checkpoints, visibility into status & responsibility, and shared responsibilities.

Enabling agility and visibility

Combining this structure with standardized JIRA tickets helped us clearly scope and roadmap each sprint and fiscal quarter with well-defined requirements and definitions-of-done.

Cross-discipline alignment

By expanding the review and approval process for each phase to include every disciplines, all team-members had insight into each step, while helping define and shape the direction of the component as it got built, rather than at the end of the process.

Through cross-discipline workshops & collaboration sessions, we re-defined and standardized our end-to-end process for agile component development and delivery.

The goals were to enable team collaboration and efficiencies through regular cross-discipline checkpoints, visibility into status & responsibility, and shared responsibilities.

Enabling agility and visibility

Combining this structure with standardized JIRA tickets helped us clearly scope and roadmap each sprint and fiscal quarter with well-defined requirements and definitions-of-done.

Cross-discipline alignment

By expanding the review and approval process for each phase to include every disciplines, all team-members had insight into each step, while helping define and shape the direction of the component as it got built, rather than at the end of the process.

definition & scope

To enable input and request from our adopters and product partners, I created new processes & templates for the 'Propose' phase.

This enabled designers and other team members to quickly define and outline the core functionality, use-cases, accessibility concerns, business value, and visual references for new components, and created easy-to-share reference documentation.

This comprehensive scoping exercise solved some of the challenges we faced in 1.0 by bringing all the disciplines together at the beginning of the process. Aligning on the goals and purpose of a new library component became a collaborative effort, with a document that was easy to share and edit.

By increasing team visibility & collaboration, we documented constraints or considerations early in the process, while also opening the door for collaborators outside of the design system team to leave comments and share their specific uses cases we needed to consider.

To enable input and request from our adopters and product partners, I created new processes & templates for the 'Propose' phase.

This enabled designers and other team members to quickly define and outline the core functionality, use-cases, accessibility concerns, business value, and visual references for new components, and created easy-to-share reference documentation.

This comprehensive scoping exercise solved some of the challenges we faced in 1.0 by bringing all the disciplines together at the beginning of the process. Aligning on the goals and purpose of a new library component became a collaborative effort, with a document that was easy to share and edit.

By increasing team visibility & collaboration, we documented constraints or considerations early in the process, while also opening the door for collaborators outside of the design system team to leave comments and share their specific uses cases we needed to consider.

To enable input and request from our adopters and product partners, I created new processes & templates for the 'Propose' phase.

This enabled designers and other team members to quickly define and outline the core functionality, use-cases, accessibility concerns, business value, and visual references for new components, and created easy-to-share reference documentation.

This comprehensive scoping exercise solved some of the challenges we faced in 1.0 by bringing all the disciplines together at the beginning of the process. Aligning on the goals and purpose of a new library component became a collaborative effort, with a document that was easy to share and edit.

By increasing team visibility & collaboration, we documented constraints or considerations early in the process, while also opening the door for collaborators outside of the design system team to leave comments and share their specific uses cases we needed to consider.

To enable input and request from our adopters and product partners, I created new processes & templates for the 'Propose' phase.

This enabled designers and other team members to quickly define and outline the core functionality, use-cases, accessibility concerns, business value, and visual references for new components, and created easy-to-share reference documentation.

This comprehensive scoping exercise solved some of the challenges we faced in 1.0 by bringing all the disciplines together at the beginning of the process. Aligning on the goals and purpose of a new library component became a collaborative effort, with a document that was easy to share and edit.

By increasing team visibility & collaboration, we documented constraints or considerations early in the process, while also opening the door for collaborators outside of the design system team to leave comments and share their specific uses cases we needed to consider.

ENABLING DESIGN

The proposal document gave myself and other designers directions for the 'Design' phase, enabling exploration and iteration based on the research & requirements, balancing flexibility and structure.

Through mentorship, async check-ins, and structured review sessions, I enabled designers to research, design, and quickly iterate over short timelines while reducing time spent in meetings.

The proposal document gave myself and other designers directions for the 'Design' phase, enabling exploration and iteration based on the research & requirements, balancing flexibility and structure.

Through mentorship, async check-ins, and structured review sessions, I enabled designers to research, design, and quickly iterate over short timelines while reducing time spent in meetings.

The proposal document gave myself and other designers directions for the 'Design' phase, enabling exploration and iteration based on the research & requirements, balancing flexibility and structure.

Through mentorship, async check-ins, and structured review sessions, I enabled designers to research, design, and quickly iterate over short timelines while reducing time spent in meetings.

The proposal document gave myself and other designers directions for the 'Design' phase, enabling exploration and iteration based on the research & requirements, balancing flexibility and structure.

Through mentorship, async check-ins, and structured review sessions, I enabled designers to research, design, and quickly iterate over short timelines while reducing time spent in meetings.

CREATING A SOURCE-of-TRUTH

This new component documentation format enabled us to socialize design decisions across disciplines and teams, define every interaction detail, & track tokens and sub-components.

The spec sheet was a shared responsibility of both designers & engineers, as it documented the states, properties, and interactions for each component using our shared API taxonomy; translating the design requirements into technical specifications.

This helped solve the biggest challenges with the 1.0 process, which included inconsistent technical documentation, team misalignment, and unstructured reviews.

We were lucky enough to be able to work with Nathan Curtis from EightShapes to develop this template, which he then adapted into the popular Specs Plugin.

This new component documentation format enabled us to socialize design decisions across disciplines and teams, define every interaction detail, & track tokens and sub-components.

The spec sheet was a shared responsibility of both designers & engineers, as it documented the states, properties, and interactions for each component using our shared API taxonomy; translating the design requirements into technical specifications.

This helped solve the biggest challenges with the 1.0 process, which included inconsistent technical documentation, team misalignment, and unstructured reviews.

We were lucky enough to be able to work with Nathan Curtis from EightShapes to develop this template, which he then adapted into the popular Specs Plugin.

This new component documentation format enabled us to socialize design decisions across disciplines and teams, define every interaction detail, & track tokens and sub-components.

The spec sheet was a shared responsibility of both designers & engineers, as it documented the states, properties, and interactions for each component using our shared API taxonomy; translating the design requirements into technical specifications.

This helped solve the biggest challenges with the 1.0 process, which included inconsistent technical documentation, team misalignment, and unstructured reviews.

We were lucky enough to be able to work with Nathan Curtis from EightShapes to develop this template, which he then adapted into the popular Specs Plugin.

This new component documentation format enabled us to socialize design decisions across disciplines and teams, define every interaction detail, & track tokens and sub-components.

The spec sheet was a shared responsibility of both designers & engineers, as it documented the states, properties, and interactions for each component using our shared API taxonomy; translating the design requirements into technical specifications.

This helped solve the biggest challenges with the 1.0 process, which included inconsistent technical documentation, team misalignment, and unstructured reviews.

We were lucky enough to be able to work with Nathan Curtis from EightShapes to develop this template, which he then adapted into the popular Specs Plugin.

finalizing

To prepare a component for delivery, both the Figma & code deliverables would be tested, accessibility reviewed, and approved by product, engineering, and design leadership.

To socialize the component we wrote and posted 'release notes', committed the new component to the Figma and code libraries, and published & shared documentation.

Documentation

I created the guidelines & markdown templates for our new documentation site, outlining sections for examples, properties, usage guidance, visuals for the various configurations, and identified content limitations and accessibility considerations.

Figma asset

I updated our QA processes, using a checklist to ensure quality and consistency in the layer naming, token usage, nested components, spacing, styling, property names, variants, scalability, and alignment to code.

To prepare a component for delivery, both the Figma & code deliverables would be tested, accessibility reviewed, and approved by product, engineering, and design leadership.

To socialize the component we wrote and posted 'release notes', committed the new component to the Figma and code libraries, and published & shared documentation.

Documentation

I created the guidelines & markdown templates for our new documentation site, outlining sections for examples, properties, usage guidance, visuals for the various configurations, and identified content limitations and accessibility considerations.

Figma asset

I updated our QA processes, using a checklist to ensure quality and consistency in the layer naming, token usage, nested components, spacing, styling, property names, variants, scalability, and alignment to code.

To prepare a component for delivery, both the Figma & code deliverables would be tested, accessibility reviewed, and approved by product, engineering, and design leadership.

To socialize the component we wrote and posted 'release notes', committed the new component to the Figma and code libraries, and published & shared documentation.

Documentation

I created the guidelines & markdown templates for our new documentation site, outlining sections for examples, properties, usage guidance, visuals for the various configurations, and identified content limitations and accessibility considerations.

Figma asset

I updated our QA processes, using a checklist to ensure quality and consistency in the layer naming, token usage, nested components, spacing, styling, property names, variants, scalability, and alignment to code.

To prepare a component for delivery, both the Figma & code deliverables would be tested, accessibility reviewed, and approved by product, engineering, and design leadership.

To socialize the component we wrote and posted 'release notes', committed the new component to the Figma and code libraries, and published & shared documentation.

Documentation

I created the guidelines & markdown templates for our new documentation site, outlining sections for examples, properties, usage guidance, visuals for the various configurations, and identified content limitations and accessibility considerations.

Figma asset

I updated our QA processes, using a checklist to ensure quality and consistency in the layer naming, token usage, nested components, spacing, styling, property names, variants, scalability, and alignment to code.

OUTCOMES

Over the course of two quarters we built, tested, and improved components and processes for 2.0, shipping brand-new 18 new components , increasing our system adoption by 31% (based on Figma data) and increasing our component delivery speed by 18%.

As our design system matured from a basic toolkit to essential infrastructure, adoption becoming the default rather than exception as our components standardized more complex UI elements.

Our usage documentation & socialization efforts reduced office hour sessions and sped up both designer & developer time for new projects, while our new QA and accessibility reviews raised the standards and quality for all adopters.

Over the course of two quarters we built, tested, and improved components and processes for 2.0, shipping brand-new 18 new components , increasing our system adoption by 31% (based on Figma data) and increasing our component delivery speed by 18%.

As our design system matured from a basic toolkit to essential infrastructure, adoption becoming the default rather than exception as our components standardized more complex UI elements.

Our usage documentation & socialization efforts reduced office hour sessions and sped up both designer & developer time for new projects, while our new QA and accessibility reviews raised the standards and quality for all adopters.

Over the course of two quarters we built, tested, and improved components and processes for 2.0, shipping brand-new 18 new components , increasing our system adoption by 31% (based on Figma data) and increasing our component delivery speed by 18%.

As our design system matured from a basic toolkit to essential infrastructure, adoption becoming the default rather than exception as our components standardized more complex UI elements.

Our usage documentation & socialization efforts reduced office hour sessions and sped up both designer & developer time for new projects, while our new QA and accessibility reviews raised the standards and quality for all adopters.

Over the course of two quarters we built, tested, and improved components and processes for 2.0, shipping brand-new 18 new components , increasing our system adoption by 31% (based on Figma data) and increasing our component delivery speed by 18%.

As our design system matured from a basic toolkit to essential infrastructure, adoption becoming the default rather than exception as our components standardized more complex UI elements.

Our usage documentation & socialization efforts reduced office hour sessions and sped up both designer & developer time for new projects, while our new QA and accessibility reviews raised the standards and quality for all adopters.

This work lives on across every Vanguard Group product and project.

Thank you to my teammates + peers for the collaboration, feedback, support and guidance (including but not limited to): Morgan Knepper, Sean Glenn, Kristine Watkins, Ben Lee, Matthew Lewis, Andrew Parry, Steven Estrella, Alex Sauls, and Wooyoung Song.