To create your first library, publish any Figma document from the Team Library modal. All of the master components and styles in this document will then become available to use in other documents. As you scale design across products or teams, especially in larger organizations, you'll want to figure out the best way to organize and distribute them for everyone to use. How many libraries should you create? How do I organize my components? Remember, the designers consuming these libraries are your end users.
We often get asked if teams should share everything from a single library or use multiple libraries. Of course the answer is, it depends! Let's look at some of the factors to consider.
Some teams, particularly smaller ones, will often create a single library to house all of their components and styles for the sake of simplicity. This approach has some benefits but a few big drawbacks as you scale.
Benefits: There is only one library for users to enable that has everything they need. There is never any confusion as to where particular components live. This also means there is only one library to maintain.
Drawbacks: For larger organizations with a lot of components and styles required to support many different platforms and products, this library can grow very quickly. If users only need a small selection of those components, they'll still have to sift through a lot of similar components they never need to use.
Many teams, especially medium-large teams, often decide the best approach is to break up their components into multiple libraries. This tends to scale much better.
Benefits: By separating components/styles into different documents/libraries, only the required libraries can be enabled for the right subset of users or teams. For example, let's say you have dedicated teams working on only mobile products. Those working on mobile may never have to consume assets designed for desktop. By splitting these into separate documents, you can publish them to separate libraries. Then, designers will only need to enable the applicable library for them, which saves them from having to sift through components they don't need to use.
Drawbacks: For those responsible for maintaining and publishing the libraries, there will be more of them to manage.
Optimizing for success: Libraries can be enabled by default for Pro teams, or across all teams in the entire company in Figma Organization. To learn more about how you might approach this, be sure to read our post on structuring teams.
The next level of library organization takes place inside each library itself. Within a document you have the ability to organize the master components in a number of ways, from naming schemes to pages and frames. You can even combine these methods in conjunction with one another.
The first and most common way to group components is with forward slash component names to organize them into a hierarchy. If you're coming from Sketch, you may already be familiar with this method. Let's say you had primary and secondary buttons with variations of each. You may choose to name them as such:
Benefits: This method is the fastest way to organize your components. Simply rename the components, and they will get organized into a hierarchy in your instance menus.
Drawbacks: While this method is a quick way to organize your components, it can result in long component names for larger systems. It is not uncommon for component names to exceed the width of your layers panel, making it more cumbersome to scan and parse the layers panel. If you are migrating from Sketch, there is nothing wrong with this method, and it will help you get up and running faster; however, if you intend to spend a bit more time laying out master components and want to include some additional information alongside them, the next method may be a better approach.
Our recommended method to organize components, is to use pages and frames as organizing containers.
Benefits: This method allows you to decouple organization from the your component naming scheme. This results in shorter component names that are easier to scan in the layers panel, and i will allow you to use a naming scheme which is closer to your system's code base.
For example, you might have a page called "Buttons", and on it a dedicated frame for each type of button ("Primary" and "Secondary") where those master components reside. This will improve the experience when navigating the thumbnails in the components panel. Page names will appear as top level headings, and frame names will appear as collapsible subheads with all the components that reside within that frame below.
This feature compliments the way many users were already starting to visually organize their library by laying out accompanying notes, annotations, proper and improper usage examples and other usage documentation alongside the master components. This way users have the ability to right click on any component instance in their document and choose "Go to Master Component", which will open the library document. Here they can view this additional information which may help them use the components in the way they were intended.
In addition, components which reside in the same containing frame are treated as related components. When you click on an instance of one of these components, the list of related ones will surface to the top level of the instance menu to make swapping between them easier. This means you don't have to hunt through the full instance menu to choose the right component.
If you require additional levels to your component hierarchy, you can still use this method and combine it with the forward slashes. If you add forward slashes, Figma will revert back to your naming scheme to determine the list of related components for subsequent levels.