Improving Adoption in PUMA’s Design System

Primary Goal

Understand design system usage and support business goals by increasing system adoption.

My Process

Assessing the Current State

When I joined the PUMA Design System team a significant amount of work on the design system had already been completed. They were past the early phases of defining foundations and deep into the weeds of building out minor components.

After a minimum viable design system is launched, it can be easy to get lost in the middle phases of growing the system as an internal product. In the case of the PUMA design system, the team had solid buy-in from designers. The increasing adoption of design system components within Figma was largely measurable using Figma’s internal tracking tools, but understanding adoption on the engineering side of the equation was much less straightforward.

Quantifying System Adoption

One of the challenges with design systems can be quantifying the long term efficiency improvements that they create in order to enable business leadership to advocate for allocating resources toward the system.

Tracking engineering adoption, when spread across multiple ecosystems can be quite complex. The team’s long term goal was to increase adoption. This meant we needed a way to measure it first. I evaluated the available tooling options to gather metrics, and I seriously considered Omlet — unfortunately at that time their platform wasn’t mature enough to gather the data we needed. So instead I wrote a custom script on top of the react-scanner package that could be run with every sprint to generate numbers tracking component adoption in our core applications. The script generated data around which components were being used and where they were used, and what percentage of app components were either system components or used system components.

Communicating with Leadership

It wasn’t a perfect measuring system, but it allowed us to go from having no data to having a benchmark of information within a couple of sprints. After cross checking the information for a few sprints, we were able to start reporting change/trend data to senior leadership every sprint. The adoption data was an accessible progress report that non-technical leadership could relate to, so it majorly strengthened our communication around system work with key business stakeholders. It also helped the systems team show that our work was aligned with business’ long term goals.

Addressing Knowledge Gap Between Engineering and the Systems Team

A known issue that our adoption data supported was that there was a lack of understanding about the system components and capabilities amongst the engineering teams building PUMA’s applications. This can be a tricky problem to solve due to design system teams being separate from the engineering organization. Ideally system awareness can be improved by creating stronger collaborative relationships between systems teams and engineering, but in PUMA’s case the constantly shifting nature of their engineering organization made this unfeasible. So instead we tackled the problem by building up documentation where the engineers naturally looked for it — enter Storybook playgrounds.

Storybook launched docs pages in their newest version around this time, and it was clear that while upgrading our 100+ component storybook instance wasn’t going to be a lot of work, there was also a clear ROI to being able to use all of our existing stories as the playground style documentation the engineering teams had told us they were looking for.

Upgrading our Storybook version and adding more real-world integration examples for improved documentation required rewriting about a third of the 100+ component stories and most of the context files to keep everything working. I followed that with an audit to make sure that all of the component parameters were noted for documentation and available in the component playgrounds.

Giving the engineering teams access to this resource significantly improved awareness of system components and capabilities within engineering teams, which quickly turned into a steady increase in system adoption within new features and fixes.

What I Learned

A lot of focus is put on the initial launch of a design system: getting the foundations right and making sure to include the right set of components, but once you get the system launched it’s long term success isn’t only up to the capabilities of the system. Without regular communication of system objectives to business leaders, ensuring that the system is supporting larger business goals, and making sure that both design and engineering teams are integrated into the systems processes a design system won’t be able to thrive as the internal product acceleration tool it is intended to be.