Adapting a component library for better adoption

Developing a UI component library for a large organisation with many different products is a challenging endeavour. A good system will strike the right balance between consistency and flexibility and will afford developers efficiency and quality. These are characteristics difficult to get right up front.

At the ABC, we are continually iterating our component library to improve a key measure of success: adoption. We want teams to want to use it! This talk will discuss some of the challenges we’ve faced, how we approach trying to find the right level of component granularity and cover some illustrative examples of the changes we’ve made to get more developers of ABC digital products on board.

Tim’s team is responsible for building components for use in any ABC product.

They thought they’d done a good job and created their components according to the composition principle, not inheritance.

The gorilla/banana inheritance problem: you wanted a banana, you got a gorilla holding a banana inside an entire jungle.

Having built a classic Card component, they found as time went on that they’d tied too much to the overall Card and not the sub-components within it. That is they’d built the component according to what it is vs what it does.

Consider what a good abstraction does – eg. if it covers 9/10 cases then it’s good. You can make a new one for the 10th, it’s ok. But as the variants stacked up, their Card had been painted into a corner. It wasn’t flexible enough to cover new cases.

A big learning: design system != pattern libary.

They broke the card out into its pieces:

  • container
  • overall layout
  • icon position
  • heading style

Then they built these out with primitive components, each doing one thing well (single responsbility principle). The primitives don’t map directly to the design system, but they do map well to the technical requirements of developers consuming the library.

Variation can then be handled by composition, not by shoving endless new props into the Card component. Build what a component does, not what it is.

Even when people are doing something custom, they can use your primitives as the base. Partial adoption is still better than none at all.