Design System Adoption in the Enterprise
By Ryan Merrill, 84.51° Experience Designer
Congratulations on the first release of your design system! The hours spent sweating the pixel-perfect details, choosing a front-end framework, and building a distribution pipeline sure weren’t easy. But now the real work begins: having the system adopted by product teams.
Without that adoption, all of the blood, sweat, and tears that went into creating bespoke components will have been for nought. But changing the ways of working for your audience of designers, engineers, and product managers isn’t going to be easy—especially in an enterprise where processes and ceremonies have been ingrained in the culture.
Enterprise adoption requires both guerrilla support from product designers and engineers, as well as a strong mandate from leadership to use the system. Without both, you’ll quickly find yourself swimming against one current or another.
Measuring Adoption
Tracking adoption shows stakeholders their initial investment in the team was well-funded and can act as a catalyst for more resources. One way to track adoption is through differing maturity levels, proposed here by Nathan Curtis. Tracking teams as they move up the stack from non-adopter to master holds them accountable to each other, encouraging a friendly competition to stay up-to-date.
It’s important to keep in mind that not all products consuming a design system will reach the mastery stage—they may be constrained by old or incompatible technology. Mapping a suite of products across an organization allows a design system team to prioritize where to put their training and outreach efforts.
Support from the bottom up
The designers, engineers, and product managers have the final say in how quickly a design system is adopted. Without their support, increasing adoption will be a long-fought battle.
Communicating design system decisions akin to Moses descending from Mt. Sinai with his stone tablets is a quick way to build resentment.
It’s imperative that the decisions communicated by the design system team have buy-in and input from members of the product teams. Communicating design system decisions akin to Moses descending from Mt. Sinai with his stone tablets is a quick way to build resentment. Don’t do this.
Include a subset of product team members in each component kick-off so everyone has their voice heard. Edge cases that may prevent a team from adopting a component will arise and can only strengthen its foundations.
The pixels and code of design systems are easy; it’s the people and relationships that are the most challenging and rewarding. As with any relationship, communication is key. As design system builders, it’s easy to get lost in the weeds and assume everyone has the context of the granular decisions that were made when building a component. Communicate to a fault. Run the risk of annoying your users about new features, modified guidelines, and deprecated components.
We created a number of regular outlets to share updates of our design system, Meridian:
- Weekly Office Hours: The team holds office hours twice a week for design system users. It’s a place where users can directly communicate with the builders of the system and ask questions, share ideas, and propose new components.
- Regular Demos: Every six weeks the design system team demonstrates what components and guidelines were published. These demos also act as a forum for users to probe the team on why certain decisions were made and can inform what is the next on the roadmap.
- Communication Channels: We use a dedicated channel in Teams to field asynchronous requests. Additional feedback and questions are posted to a dedicated and monitored forum or sent via email.
Support from the top down
Getting the initial investment from leadership of a design system in an enterprise is no small feat. But it’s equally important that leadership communicates the need for product teams to use the system.
It’s too easy for product teams to become mired in the day-to-day work and de-prioritize design system adoption. Leadership needs to have a persistent and vocal push about the importance of adopting the design system for an entire suite of products.
An extension of the product team
Even with a groundswell of enthusiasm from those pushing pixels and with leaders espousing their support, design system adoption can still be slow-going. It might take a bit of handholding from the design system team to help combat some of this systems adverse thinking.
The pixels and code of design systems are easy; it’s the people and relationships that are the most challenging and rewarding.
The builders of the design system know the components, guidelines, and best practices better than anyone—putting them in a perfect place to act as guides. The system team can generate goodwill on product teams by pairing with engineers when tackling thorny problems or participating in design critiques. This symbiotic relationship helps everyone by giving product teams an extra set of hands and educates the systems team in that much needed product context.
This is a long play
Design system work is difficult. Migrating an enterprise away from siloed-to-systems thinking won’t happen overnight.
Creating a way for teams to track adoption can help an organization measure their design system investments and give struggling product teams the resources they need. The bulk of the work falls on the design system team to communicate clearly, effectively, and inclusively. That communication, coupled with a top-down push from leadership, will help sow the seeds for a burgeoning adoption.
