SIM

Role

VP of Product Experience

Team

3 Product Designers

1 Product Manager

2 Front-end Developers

Timeline

18 Months

Responsibilities

I set the vision, led execution, and guided adoption across product, design, and engineering

Suzy Design System

Journey From Nice-To-Have to Must-Have

01.

Overview

image of a diagram showing atomic design system

Context

Suzy was originally built on a Material Design Angular template. With a frontend engineer, two backend engineers, and limited time, the template gave us the speed we needed to get the product off the ground.

​

As Suzy grew, the pace and complexity grew with it. Multiple teams shipped features at high speed, and the product began to lose cohesion. The advantage of the template eventually turned into a limitation, resulting in accumulation of design and technical debt.

​

To stop the product experience from degrading further, I made the case to leadership and established the Design System as the foundation we'd need for future product development.

Challenge

Despite Suzy’s strong design maturity, a Design System was a hard initiative to prioritize. Revenue-driving features always won the roadmap, and it wasn’t easy to justify pulling designers and engineers into internal tooling.

​

Leadership understood the long-term value, but hesitated because it could slow feature delivery or trigger large redesign efforts. Design System work had to be done without impacting product velocity.

02.

Approach

02

Recruit Champions

I formed a small cross-functional group called the Guardians of Design System (GODS). They owned key decisions, shaped early standards, and served as the point of contact for their teams. Giving them real ownership strengthened adoption across the organization.

03

Vision and Standards

I set the vision for the Design System and established the standards and governance to support it. By defining how each team contributed, we kept decisions aligned, reinforced ownership, and made the rollout predictable.

06

Shared Ownership

We shared early wins, made the work visible, and invited feedback from anyone interested. This helped the team feel invested in the Design System, increased contributors, and supported natural adoption across teams.

01

Stakeholder Buy-In

I identified product inefficiencies, mapped inconsistencies, and shared the findings with design, engineering, and product leadership. This created shared goals and secured the sponsorship needed to start the Design System.

04

Evolve as We Build

I prioritized a feature-first approach. We built components required by new features, then expanded the library. This kept the system relevant and ensured every component solved a real product need.

05

Minimum 1% Update

To keep progress steady, I secured a commitment for ongoing DS work. We aimed for 10% of every sprint, with a hard minimum of 1%. This ensured no sprint shipped without a Design System update.

03.

Journey

Timeline

H1 2024

Continuous Improvement

  • Design System fully embedded into product workflow
  • Kicked off platform-wide screen rebuild
  • Every sprint included product improvement work
  • Began laying the foundation for future brand updates

H1 2023

Build

  • Established Figma -> Storybook token automation pipeline
  • Core components live in production
  • Rebuilt and stress-tested existing screens with Design System components
  • Switched to hi-fi workflow to speed up delivery

H2 2002

Foundation

  • Secured stakeholder alignment
  • Formed the Design System Team
  • Defined scope, vision, and long-term direction
  • Established cross-team workflow and governance
  • Aligned on design system foundation

H2 2023

Integration & Scale

  • Integrated Design System into the product workflow
  • Majority of components running in production
  • New features were built entirely with Design System components
  • ~40% of existing screens rebuilt

Standard & Governance

Organization and naming conventions were the first things I tackled. I treated the design system as a large-scale front-end project, where structure and standards require careful thinking to scale without introducing chaos. These are the kinds of decisions that are painful to change later and should not shift frequently once established.

​

Files were structured around a clear separation between foundations and components. Foundations such as spacing, color, typography, and brand elements defined the core design decisions of the product. The goal was to ensure both designers and non-designers could locate files easily and confidently.

​

I opted to treat each component and foundation as an individual file. This setup made it easier to manage, scale, and keep the version history clean.

timeline

To maintain a consistent file structure, a template page was created and used as the starting point for every file. Each file was self-contained and included its own documentation, stress-test examples, and audit context when extending or replacing existing elements. This approach supported scalability. However, managing imports across files remained more manual than it should have been, as Figma’s system import capabilities had not yet evolved to fully support this workflow.

timeline

Files are organized in foundations and components. Foundations are made of spaces, colors, typographys and other that derived from the brand. These foundations eventually turned into tokens.

We placed strong emphasis on documentation because it defined the shared guidelines and language across the product. Documentation was treated as a core part of the system, clarifying intent and reducing ambiguity as teams scaled. Documentation was continuously reviewed and refined as the system matured.

timeline

Files are organized in foundations and components. Foundations are made of spaces, colors, typographys and other that derived from the brand. These foundations eventually turned into tokens.

Storybook was selected as the UI library for developers. We built a tool that extracted variables from Figma and transformed them into design variables ready for use across platforms, including web, iOS, and Android.

Components

timeline

“Build it like a developer would” was the mindset I wanted my designers to adopt. Since the team did not have front-end development experience, I coached them on how to design and scale components engineers expect. It took time, but I was proud of how the team grew into this way of thinking.

The text input shown above appears simple, but it was composed of multiple smaller components. Constant review cycles ensured the component stayed flexible without becoming over-configured. Designers were treated as users of the system, and their needs directly informed the final component specifications

timeline

There has always been debate around starting in high fidelity. After research and discussion, we aligned that high fidelity provided more value for most of our work, while still leaving room for low fidelity in specific cases. High fidelity became our default, not a rigid rule.

When we built more than 75 core components, our team switched to hi-fi solution. With design system and strong documentation foundation, our designer was able to ship design 50% faster and with more accurate presesentation.

Process

timeline

The process is not as linear as described above. We have tweak our process throughout the project but above is the general flow. Due to nature of our project setup, the most important step of the process is step 4. It had the highest touch points and coordinations with multiple team. That is the step where we plan what can be ship.

Due to nature of our project setup, the most important step of the process is step 4. It had the highest touch points and coordinations with multiple team. That is the step where we plan what can be ship.

04.

Before ANd After

The Design System work went beyond UI polish and component creation. We used this effort as an opportunity to address long-standing UX issues that had accumulated in the backlog.

By standardizing layout, spacing, and component behavior, we were able to improve information density, reduce unnecessary vertical space, and simplify high-traffic workflows. Many of these changes were informed by existing user feedback and internal pain points rather than visual preference alone

The original screen used legacy Material Design v1 line-only inputs, which led to unclear boundaries and inconsistent spacing in a long configuration flow.

We brought back outlined inputs to restore clear boundaries between fields. Fields were reorganized into more logical groups to improve readability and flow. The Suzy Grid System was applied to standardize spacing across sections, reducing wasted vertical space by about 8%.

timeline

In this example, the original screen overused the brand color across actions, with multiple shades of purple competing for attention and weakening the meaning of primary actions. A persistent primary button dominated the header, even though the page’s intent was to review results. We standardized brand color usage, reduced primary actions, and reserved primary button for true next steps. This clarified action hierarchy, reinforced brand consistency, and made the results experience easier to focus on without removing functionality.

timeline

05.

outcome

"By 2024, we speak the same design language."

Vision that ancored The team

Consistency Across Pods

Six separate features, worked on by separate

pods in Q4 2023, all were build using Suzy Design System components. 0 design inconsistency bugs across the 6 features.

68% Lighter Code

We were able to shred 2/3 repeatable code resulted in faster load time. Developer also gained 30% increased in productivity by utilizing share components.

Design operation improved by 50%

Design team skipped low-fi wires and delivered in full flows in high-fi. For a project that used to take 2 sprints of work became 1 sprint.

GTM Ready

The Design System enabled true collaboration between Product and GTM. Because production mirrored the design, GTM materials could be prepared in advance, reducing Product as a bottleneck in the GTM process.

1M+ Efficiency Value

With teams of 8 designers and 10 front-ends, we saw an average of 45% increased in efficiency value which could translated to 1M+ annually worth of spending now allocated to more high value work.

100% adoption by Q2 2024

Suzy design system was fully embeded into product development life-cycle. Figma's components are fully build on storybook with easy token syncing.

06.

Learning

3 Teams. 1 system to rule them all

One thing I’d do differently is make measurable benchmarks a mandatory part of the process from the start. Setting the right metrics that measure cross-team impact takes time, and having that alignment earlier with FE, PM, and design would have given us clearer signals of progress along the way. I also realized that the technical execution itself wasn’t the hard part. The real work was keeping momentum high and morale steady for a long-term initiative where most of the benefits don’t show up until the very end. A Design System only becomes fully embedded when champions stay committed, and their ongoing push is what ultimately carried the system across the finish line.Special shoutout to the DS's core team - Alexa, Brock, Dara, Michelle, Eric, Mary Ann, Brock, Alexa and Haseeb.

SIM

Role

VP of Product Experience

Team

3 Product Designers

1 Product Manager

2 Front-end Developers

Timeline

18 Months

Responsibilities

I set the vision, led execution, and guided adoption across product, design, and engineering

Suzy Design System

Journey From Nice-To-Have to Must-Have

01.

Overview

image of a diagram showing atomic design system

Context

Suzy was originally built on a Material Design Angular template. With a frontend engineer, two backend engineers, and limited time, the template gave us the speed we needed to get the product off the ground.

​

As Suzy grew, the pace and complexity grew with it. Multiple teams shipped features at high speed, and the product began to lose cohesion. The advantage of the template eventually turned into a limitation, resulting in accumulation of design and technical debt.

​

To stop the product experience from degrading further, I made the case to leadership and established the Design System as the foundation we'd need for future product development.

Challenge

Despite Suzy’s strong design maturity, a Design System was a hard initiative to prioritize. Revenue-driving features always won the roadmap, and it wasn’t easy to justify pulling designers and engineers into internal tooling.

​

Leadership understood the long-term value, but hesitated because it could slow feature delivery or trigger large redesign efforts. Design System work had to be done without impacting product velocity.

02.

Approach

01

Stakeholder Buy-In

I identified product inefficiencies, mapped inconsistencies, and shared the findings with design, engineering, and product leadership. This created shared goals and secured the sponsorship needed to start the Design System.

03

Vision and Standards

I set the vision for the Design System and established the standards and governance to support it. By defining how each team contributed, we kept decisions aligned, reinforced ownership, and made the rollout predictable.

06

Shared Ownership

We shared early wins, made the work visible, and invited feedback from anyone interested. This helped the team feel invested in the Design System, increased contributors, and supported natural adoption across teams.

02

Recruit Champions

I formed a small cross-functional group called the Guardians of Design System (GODS). They owned key decisions, shaped early standards, and served as the point of contact for their teams. Giving them real ownership strengthened adoption across the organization.

04

Evolve as We Build

I prioritized a feature-first approach. We built components required by new features, then expanded the library. This kept the system relevant and ensured every component solved a real product need.

05

Minimum 1% Update

To keep progress steady, I secured a commitment for ongoing DS work. We aimed for 10% of every sprint, with a hard minimum of 1%. This ensured no sprint shipped without a Design System update.

03.

Journey

Timeline

H2 2002

Foundation

  • Secured stakeholder alignment
  • Formed the Design System Team
  • Defined scope, vision, and long-term direction
  • Established cross-team workflow and governance
  • Aligned on design system foundation

H1 2024

Continuous Improvement

  • Design System fully embedded into product workflow
  • Kicked off platform-wide screen rebuild
  • Every sprint included product improvement work
  • Began laying the foundation for future brand updates

H1 2023

Build

  • Established Figma -> Storybook token automation pipeline
  • Core components live in production
  • Rebuilt and stress-tested existing screens with Design System components
  • Switched to hi-fi workflow to speed up delivery

H2 2023

Integration & Scale

  • Integrated Design System into the product workflow
  • Majority of components running in production
  • New features were built entirely with Design System components
  • ~40% of existing screens rebuilt

Standard & Governance

To maintain a consistent file structure, a template page was created and used as the starting point for every file. Each file was self-contained and included its own documentation, stress-test examples, and audit context when extending or replacing existing elements. This approach supported scalability. However, managing imports across files remained more manual than it should have been, as Figma’s system import capabilities had not yet evolved to fully support this workflow.

timeline

Organization and naming conventions were the first things I tackled. I treated the design system as a large-scale front-end project, where structure and standards require careful thinking to scale without introducing chaos. These are the kinds of decisions that are painful to change later and should not shift frequently once established.

​

Files were structured around a clear separation between foundations and components. Foundations such as spacing, color, typography, and brand elements defined the core design decisions of the product. The goal was to ensure both designers and non-designers could locate files easily and confidently.

​

I opted to treat each component and foundation as an individual file. This setup made it easier to manage, scale, and keep the version history clean.

timeline

Files are organized in foundations and components. Foundations are made of spaces, colors, typographys and other that derived from the brand. These foundations eventually turned into tokens.

We placed strong emphasis on documentation because it defined the shared guidelines and language across the product. Documentation was treated as a core part of the system, clarifying intent and reducing ambiguity as teams scaled. Documentation was continuously reviewed and refined as the system matured.

timeline

Files are organized in foundations and components. Foundations are made of spaces, colors, typographys and other that derived from the brand. These foundations eventually turned into tokens.

Storybook was selected as the UI library for developers. We built a tool that extracted variables from Figma and transformed them into design variables ready for use across platforms, including web, iOS, and Android.

Components

timeline

“Build it like a developer would” was the mindset I wanted my designers to adopt. Since the team did not have front-end development experience, I coached them on how to design and scale components engineers expect. It took time, but I was proud of how the team grew into this way of thinking.

The text input shown above appears simple, but it was composed of multiple smaller components. Constant review cycles ensured the component stayed flexible without becoming over-configured. Designers were treated as users of the system, and their needs directly informed the final component specifications

timeline

There has always been debate around starting in high fidelity. After research and discussion, we aligned that high fidelity provided more value for most of our work, while still leaving room for low fidelity in specific cases. High fidelity became our default, not a rigid rule.

When we built more than 75 core components, our team switched to hi-fi solution. With design system and strong documentation foundation, our designer was able to ship design 50% faster and with more accurate presesentation.

Process

timeline

When we built more than 75 core components, our team switched to hi-fi solution. With design system and strong documentation foundation, our designer was able to ship design 50% faster and with more accurate presesentation.

When we built more than 75 core components, our team switched to hi-fi solution. With design system and strong documentation foundation, our designer was able to ship design 50% faster and with more accurate presentation. Creating a concept prototype that consistence with our platform was a breeze and believable to stakeholders.

Due to nature of our project setup, the most important step of the process is step 4. It had the highest touch points and coordinations with multiple team. That is the step where we plan what can be ship.

04.

Before ANd After

The Design System work went beyond UI polish and component creation. We used this effort as an opportunity to address long-standing UX issues that had accumulated in the backlog.

By standardizing layout, spacing, and component behavior, we were able to improve information density, reduce unnecessary vertical space, and simplify high-traffic workflows. Many of these changes were informed by existing user feedback and internal pain points rather than visual preference alone

We brought back outlined inputs to restore clear boundaries between fields. Fields were reorganized into more logical groups to improve readability and flow. The Suzy Grid System was applied to standardize spacing across sections, reducing wasted vertical space by about 8%.

The original screen used legacy Material Design v1 line-only inputs, which led to unclear boundaries and inconsistent spacing in a long configuration flow.

timeline

In this example, the original screen overused the brand color across actions, with multiple shades of purple competing for attention and weakening the meaning of primary actions. A persistent primary button dominated the header, even though the page’s intent was to review results. We standardized brand color usage, reduced primary actions, and reserved primary button for true next steps. This clarified action hierarchy, reinforced brand consistency, and made the results experience easier to focus on without removing functionality.

timeline

05.

outcome

"By 2024, we speak the same design language."

Vision that ancored The team

Consistency Across Pods

Six separate features, worked on by separate

pods in Q4 2023, all were build using Suzy Design System components. 0 design inconsistency bugs across the 6 features.

68% Lighter Code

We were able to shred 2/3 repeatable code resulted in faster load time. Developer also gained 30% increased in productivity by utilizing share components.

Design operation improved by 50%

Design team skipped low-fi wires and delivered in full flows in high-fi. For a project that used to take 2 sprints of work became 1 sprint.

GTM Ready

The Design System enabled true collaboration between Product and GTM. Because production mirrored the design, GTM materials could be prepared in advance, reducing Product as a bottleneck in the GTM process.

1M+ Efficiency Value

With teams of 8 designers and 10 front-ends, we saw an average of 45% increased in efficiency value which could translated to 1M+ annually worth of spending now allocated to more high value work.

100% adoption by Q2 2024

Suzy design system was fully embeded into product development life-cycle. Figma's components are fully build on storybook with easy token syncing.

06.

Learning

One thing I’d do differently is make measurable benchmarks a mandatory part of the process from the start. Setting the right metrics that measure cross-team impact takes time, and having that alignment earlier with FE, PM, and design would have given us clearer signals of progress along the way. I also realized that the technical execution itself wasn’t the hard part. The real work was keeping momentum high and morale steady for a long-term initiative where most of the benefits don’t show up until the very end. A Design System only becomes fully embedded when champions stay committed, and their ongoing push is what ultimately carried the system across the finish line.Special shoutout to the DS's core team - Alexa, Brock, Dara, Michelle, Eric, Mary Ann, Brock, Alexa and Haseeb.

3 Teams. 1 system to rule them all

SIM

Role

VP of Product Experience

Team

3 Product Designers

1 Product Manager

2 Front-end Developers

Timeline

18 Months

Responsibilities

I set the vision, led execution, and guided adoption across product, design, and engineering

Suzy Design System

Journey From Nice-To-Have to Must-Have

01.

Overview

Context

Suzy was originally built on a Material Design Angular template. With a frontend engineer, two backend engineers, and limited time, the template gave us the speed we needed to get the product off the ground.

​

As Suzy grew, the pace and complexity grew with it. Multiple teams shipped features at high speed, and the product began to lose cohesion. The advantage of the template eventually turned into a limitation, resulting in accumulation of design and technical debt.

​

To stop the product experience from degrading further, I made the case to leadership and established the Design System as the foundation we'd need for future product development.

Challenge

Despite Suzy’s strong design maturity, a Design System was a hard initiative to prioritize. Revenue-driving features always won the roadmap, and it wasn’t easy to justify pulling designers and engineers into internal tooling.

​

Leadership understood the long-term value, but hesitated because it could slow feature delivery or trigger large redesign efforts. Design System work had to be done without impacting product velocity.

image of a diagram showing atomic design system

02.

Approach

01

Stakeholder Buy-In

I identified product inefficiencies, mapped inconsistencies, and shared the findings with design, engineering, and product leadership. This created shared goals and secured the sponsorship needed to start the Design System.

02

Recruit Champions

I formed a small cross-functional group called the Guardians of Design System (GODS). They owned key decisions, shaped early standards, and served as the point of contact for their teams. Giving them real ownership strengthened adoption across the organization.

03

Vision and Standards

I set the vision for the Design System and established the standards and governance to support it. By defining how each team contributed, we kept decisions aligned, reinforced ownership, and made the rollout predictable.

04

Evolve as We Build

I prioritized a feature-first approach. We built components required by new features, then expanded the library. This kept the system relevant and ensured every component solved a real product need.

05

Minimum 1% Update

To keep progress steady, I secured a commitment for ongoing DS work. We aimed for 10% of every sprint, with a hard minimum of 1%. This ensured no sprint shipped without a Design System update.

06

Shared Ownership

We shared early wins, made the work visible, and invited feedback from anyone interested. This helped the team feel invested in the Design System, increased contributors, and supported natural adoption across teams.

03.

Journey

Timeline

H2 2002

Foundation

  • Secured stakeholder alignment
  • Formed the Design System Team
  • Defined scope, vision, and long-term direction
  • Established cross-team workflow and governance
  • Aligned on design system foundation

H1 2024

Continuous Improvement

  • Design System fully embedded into product workflow
  • Kicked off platform-wide screen rebuild
  • Every sprint included product improvement work
  • Began laying the foundation for future brand updates

H2 2023

Integration & Scale

  • Integrated Design System into the product workflow
  • Majority of components running in production
  • New features were built entirely with Design System components
  • ~40% of existing screens rebuilt

H1 2023

Build

  • Established Figma -> Storybook token automation pipeline
  • Core components live in production
  • Rebuilt and stress-tested existing screens with Design System components
  • Switched to hi-fi workflow to speed up delivery

Standard & Governance

Organization and naming conventions were the first things I tackled. I treated the design system as a large-scale front-end project, where structure and standards require careful thinking to scale without introducing chaos. These are the kinds of decisions that are painful to change later and should not shift frequently once established.

​

Files were structured around a clear separation between foundations and components. Foundations such as spacing, color, typography, and brand elements defined the core design decisions of the product. The goal was to ensure both designers and non-designers could locate files easily and confidently.

​

I opted to treat each component and foundation as an individual file. This setup made it easier to manage, scale, and keep the version history clean.

timeline

To maintain a consistent file structure, a template page was created and used as the starting point for every file. Each file was self-contained and included its own documentation, stress-test examples, and audit context when extending or replacing existing elements. This approach supported scalability. However, managing imports across files remained more manual than it should have been, as Figma’s system import capabilities had not yet evolved to fully support this workflow.

timeline

Visual designers and UX designers worked in parallel. Visual designers focused on visual and component structure, while UX designers audited and defined component usage.

We placed strong emphasis on documentation because it defined the shared guidelines and language across the product. Documentation was treated as a core part of the system, clarifying intent and reducing ambiguity as teams scaled. Documentation was continuously reviewed and refined as the system matured.

timeline

Design tokens are the language bridging design in Figma and the codebase. Designers and developers aligned on naming conventions to avoid translation gaps between Figma and code.

Storybook was selected as the UI library for developers. We built a tool that extracted variables from Figma and transformed them into design variables ready for use across platforms, including web, iOS, and Android.

Components

timeline

“Build it like a developer would” was the mindset I wanted my designers to adopt. Since the team did not have front-end development experience, I coached them on how to design and scale components engineers expect. It took time, but I was proud of how the team grew into this way of thinking.

The text input shown above appears simple, but it was composed of multiple smaller components. Constant review cycles ensured the component stayed flexible without becoming over-configured. Designers were treated as users of the system, and their needs directly informed the final component specifications

timeline

There has always been debate around starting in high fidelity. After research and discussion, we aligned that high fidelity provided more value for most of our work, while still leaving room for low fidelity in specific cases. High fidelity became our default, not a rigid rule.

After building more than 75 core components, the team fully shifted to high-fidelity workflows. Supported by a design system and clear documentation, designers shipped 50 percent faster with more accurate representations of the product. Concept prototypes felt consistent with the platform and credible to stakeholders.

Process

timeline

The process is not as linear as described above. We have tweak our process throughout the project but above is the general flow.

Due to nature of our project setup, the most important step of the process is step 4. It had the highest touch points and coordinations with multiple team. That is the step where we plan what can be ship.

04.

Before ANd After

The Design System work went beyond UI polish and component creation. We used this effort as an opportunity to address long-standing UX issues that had accumulated in the backlog.

By standardizing layout, spacing, and component behavior, we were able to improve information density, reduce unnecessary vertical space, and simplify high-traffic workflows. Many of these changes were informed by existing user feedback and internal pain points rather than visual preference alone

timeline

In this example, the original screen overused the brand color across actions, with multiple shades of purple competing for attention and weakening the meaning of primary actions. A persistent primary button dominated the header, even though the page’s intent was to review results. We standardized brand color usage, reduced primary actions, and reserved primary button for true next steps. This clarified action hierarchy, reinforced brand consistency, and made the results experience easier to focus on without removing functionality.

timeline

The original screen used legacy Material Design v1 line-only inputs, which led to unclear boundaries and inconsistent spacing in a long configuration flow.

We brought back outlined inputs to restore clear boundaries between fields. Fields were reorganized into more logical groups to improve readability and flow. The Suzy Grid System was applied to standardize spacing across sections, reducing wasted vertical space by about 8%.

05.

outcome

"By 2024, we speak the same design language."

Vision that anchored The team

Consistency Across Pods

Six separate features, worked on by separate

pods in Q4 2023, all were build using Suzy Design System components. 0 design inconsistency bugs across the 6 features.

68% Lighter Code

We were able to shred 2/3 repeatable code resulted in faster load time. Developer also gained 30% increased in productivity by utilizing share components.

Design operation improved by 50%

Design team skipped low-fi wires and delivered in full flows in high-fi. For a project that used to take 2 sprints of work became 1 sprint.

GTM Ready

The Design System enabled true collaboration between Product and GTM. Because production mirrored the design, GTM materials could be prepared in advance, reducing Product as a bottleneck in the GTM process.

1M+ Efficiency Value

With teams of 8 designers and 10 front-ends, we saw an average of 45% increased in efficiency value which could translated to 1M+ annually worth of spending now allocated to more high value work.

100% adoption by Q2 2024

Suzy design system was fully embedded into product development life-cycle. Figma's components are fully build on storybook with easy token syncing.

06.

Learning

One thing I’d do differently is make measurable benchmarks a mandatory part of the process from the start. Setting the right metrics that measure cross-team impact takes time, and having that alignment earlier with FE, PM, and design would have given us clearer signals of progress along the way. I also realized that the technical execution itself wasn’t the hard part. The real work was keeping momentum high and morale steady for a long-term initiative where most of the benefits don’t show up until the very end. A Design System only becomes fully embedded when champions stay committed, and their ongoing push is what ultimately carried the system across the finish line.Special shoutout to the DS's core team - Alexa, Brock, Dara, Eric, Haseeb, Mary Ann and Michelle.

3 Teams. 1 system to rule them all