How many component libraries should we have ideally? Pros and Cons?

I’m looking at soon cleaning up our component libraries and weighing a couple structural options, i.e. how many component libraries should we have? Very curious for input and opinions on these options:

1. A separate library file for each component. For ease of use, we think we’d have to bring these all into a single kit library file where we wrap each component in an outer component wrapper and then publish those. This way designers can subscribe to a single library.

Pros: makes using Figma branches very light and clean on component files

Cons: most of these library files will all have to subscribe to each other in order to compose larger components from atomic ones. Updates might involve lots of nested published updates.

Question: Does this impact memory/performance in a similar way to having hundreds of variants in a component?

2. One big component library. This might now be possible with variables and greatly reduced variant matrices?

Pros: composition of nested atomic components and updates like that happen automatically

Cons: branching usually gets messy with multiple designers working on a single library

Question: Any other concerns or gotchas here?

3. A handful of libraries grouped by component category. e.g. Controls, Containers, Inputs, Messaging, etc.
Pros: branching should still be clean as update efforts are usually limited to a single component category.
Cons: libraries will still have to subscribe to each other but at least the numbers are lower than Option 1.

1 Like

In my three years of hands-on experience with design systems, I’ve experimented with each of the approaches you’ve outlined here. When I first started, I leaned towards a separate library for each component. My thought was that this would offer greater granularity and better organization. However, the reality was quite the opposite. The overhead in managing multiple libraries started consuming a significant amount of time. Every time a change was made to a common variable like color or typography, propagating that change across multiple libraries became a herculean task.

My next move was to option 3, where I categorized components into a handful of libraries based on their use case or object type. This felt like a happy medium, with a more manageable number of libraries and logical groupings that made components easier to find. But even then, there were some challenges around redundancy and reusability.

Fast-forward to today, and what I’ve settled on is actually a hybrid between options 2 and 3. This approach leverages the best of both worlds. By having centralized libraries and external libraries for not-in-context published projects (ex. iOs 17 design system) , I’ve drastically reduced the overhead in components management. I don’t need to jump between multiple files or worry about inconsistencies. At the same time, by using variables, I’ve been able to introduce a level of flexibility that almost mimics having separate libraries. For example, in our multi-brand design system, variables are defined at the “primary” level, which then branches out into specific brand implementations into another project for a sub-brand. This makes it easier to manage changes across multiple brands without sacrificing the specificity that a separate library for each would offer.

1 Like

Thanks, really valuable perspective. I think we are settling on attempting to have a single library, but if it gets too large, we will decide on the policy for how to split the library ahead of time so we can prepare for it.