The hub and spoke design system model

No design system team can scale enough to support an enterprise scale business by itself. IBM Carbon's hub and spoke model has been success in combining a common core with empowered delivery teams.

In around 2018/2019, the IBM Carbon Design System team started to notice the emergence of business unit specific “pattern and asset library” (PAL) sites. These sites often lifted content directly from the Carbon site’s documentation and guidance. And then added new guidance, new components, and further direction. It seemed like the business units were creating PALs to be one stop shops for their designers and developers, and our initial response was negative. We feared we’d end up with a bunch of PAL sites that were really just a return to having multiple design systems. Even if they shared the same original DNA, they’d quickly fracture and become inconsistent in design and implementation.

Matt Rosno, product manager on the Carbon team, took a different stance. He identified the emergence of these PAL sites as an opportunity, as much as a danger. Their growth demonstrated a clear demand for the advantages that we were trying to provide with the Carbon Design System. Business units needed extra capability to tailor how the design system was going to be consumed in their domain.

Instead of pushing back against the development, we chose to lean in. Matt took the lead in engaging with the various teams who were building, or thinking of building, PALs. He identified the needs that they were trying to serve, and found that these business units were all basically trying to solve the same problems.

It became clear that this could be a catalyst to really embed Carbon usage culturally throughout IBM. We’d give a structure, guidance, and resources that would empower business units to extend and improve Carbon, ship their products, and then have a low-friction path to push their work back into the design system ecosystem for everyone else to use.

The core design system team created a website template for every business unit to use if they wanted to build a PAL site, and a naming convention for those PALs. It meant those sites were consistently presented, and clearly part of a broader Carbon community” We also created content templates, such as a component usage guidance template. New components built outside of the Carbon team would be documented in the same format as core components. We provided links to the PAL sites from the main Carbon website. And, a little later, we shipped a community component index in the Carbon website, providing an additional component resource from the universal component index.

By creating an easy, default, path for these satellite, or spoke, sites, we facilitated consistency. And we redirected efforts that might have potentially created work that undermined the aim of a universal design system to work that supported that ecosystem. All of this while following the principles I outlined a couple of weeks back in the three types of design system deviation.

We ended up defining a model something like this.

This diagram is a couple of years old now, and the ecosystem has continued to evolve and, in some cases, consolidate. But the principles of this hub and spoke model remain consistent. The central Carbon “core” provides common or universal guidance and resourcing. Business units’ PAL sites are the spokes, where specificity is added in their domain area, additional information and guidance, and extended functionality. But not replication or deviation. And individual product teams reference both their business unit PAL, and the core Carbon site.

But, while their specific domain PAL might be a primary reference for a product team, horizontal sharing is also possible. In fact, it’s vital. In the above diagram, a team in IBM Security might use the 34 common Carbon components and 5 components their own “Carbon for Security” PAL team has built. But they could also consume a component that the “Carbon for Cloud” PAL team has built, if it meets their needs.

What teams build to ship their product is additive to the design system as a whole. It’s available for everyone (at least, everyone within IBM, and some PALs share more work publicly) to take, use, and improve. The Carbon steering committee can also see all this work, and use it to help guide the community. Visibility is a huge driver of de-duplication of effort. And the community as a whole benefits.

There are numerous inflection points during the evolution of a design system. Many of those occur for the same fundamental reason. It is impossible to scale a design system team enough to directly support every demand from an enterprise scale business. The design system team will always be a bottleneck unless a structure can be built which empowers business units and product teams to support themselves. The hub and spoke (also called “core + federated”) model is not the only solution, but it’s enabled Carbon to evolve an ecosystem that maintains design system compliance while driving innovation and evolution at the business unit and team level. All of which drives further growth of the design system and its community.