Figma Support Forum

Design Systems: Single Library v. Multiple Libraries

Hi fellow Figma Users,

I am working on setting up the foundation for my companies design system. I am curious to know if there are best practices or thoughts around the number of libraries used. Is it better to have a single library that includes everything (colors, typography, icons, and components)? Or is it better to split them out into separate libraries? My two main concerns are the maintenance of the design system and usability for designers.

Thanks in advance!


It depends on the size of the company, but a lot of bigger companies are moving towards a “system of systems” kind of approach. in practice this usually looks like:

  • A single “foundation/base” library with common styles, colors, icons, etc that everything uses

  • Platform based libraries (Mobile, Web, desktop apps, etc)

  • Multiple, more specific sub-libraries branching off of the platform libraries

This approach has worked really well in my experience, especially if you have multiple teams/designers managing each library. The structure above feels like a good balance. We’ve had designers get annoyed by having to enable/disable too many libraries so keep that in mind too. Hope this helps!!

1 Like

Great question @Montana_Blum, as my team found ourselves facing the same crossroads you are currently. We iterated several times before landing on a final direction which is more of a “System of Systems” as @Kyle_Smith mentioned. For context, we’re an enterprise software company so we have a significant amount of features and corresponding design tokens.

Here’s where we landed at our approach to managing our designs, starting at the highest level (project and file structures), down to the tactical side (where design system components live, in which files).

Project and File structure:

Design System Project

  • Design System files: this is home to our design tokens, mostly “atoms” and some “molecules”

Feature Projects

  • Our features frequently undergo design/development iterations, so we decided that each large feature demanded it’s own project for ease of navigating to design files pertaining to these features.

  • Files inside of a Feature project:
    ** Specs/Components file - this file is home to the Design System specific to this feature. This includes fully vetted and approved design components that are used in future design/development initiatives, as well as cross-feature referencing. These components use our primary Design System atoms/molecules and custom-designs to create full-fledged “Organisms” specific to this feature.
    ** Epic/User-Story design files - for each Epic, we have an individual design file inside of the feature project, where new designs and requirements are defined and prepared for developer handoff. After development, if any of these new designs are intended to update the current designs, then these new designs are used to update the Features “Design System”

This certainly isn’t a one-size-fits-all approach, but it works for our team and our developers have expressed a ton of appreciation for this new structure. They absolutely love the way we’ve created individual design files per Epic (as opposed to them scouring through a massive design file, with tons of pages with all designs in a single file).

If you type this into “ design system” this will search the old Figma forum which had a ton of good advice on design system architecture.