The team was updating the design system without a shared framework for how to structure it. Explorations lived alongside production-ready components in the same files. Multiple versions of the same element existed without clear hierarchy. Until at one point, the term Atomic Design came up.

This became the pivot point for my contribution.

I introduced the team to atomic design methodology. How tokens, elements, components, and patterns nest to form a scalable system. I walked through how this mapped to the way the company already structures its other design systems, making the framework feel familiar rather than foreign. From there, I established conventions for how to migrate components from exploration files to the production system without breaking dependencies. A problem the team had been hitting repeatedly, because deleting an original exploration component would orphan every instance built from it.

This wasn't a mandate from above. It was a gap I identified and filled because the team needed it and I had the knowledge.

The restructured system followed atomic principles and aligned with the company's broader design system conventions. Components had clear relationships. What depends on what, what lives where, what's safe to change and what will cascade. The file management practices I introduced reduced the version confusion that had been slowing the team down.

More importantly, the team internalized a framework they could apply going forward. The conversation that started with "do you know what atomic design is?" ended with engineering and design sharing a common vocabulary for how the system should scale.