Team Libraries in Figma

Today, we’re excited to announce the beta release of Team Libraries for sharing components across projects. With this release, we build on the foundation we established with Components to make design systems easier to create, maintain and use across an entire team. Team Libraries are available in the product today at

The problem

Many prevalent problems in product design today stem from the fact that most design tools were built to imitate traditional print design tools.

The core of these applications were either built for editing photos, doing complex illustration work, or making static rectangles with text on them. Physical paper doesn’t have interactivity, so while you could draw pictures of applications with these tools, they’d never really understand how the app would actually behave in different contexts. Communicating realistic application behavior in a static artboard or using constraints that don’t actually exist in a platform’s API just isn’t good enough.

To make matters worse, your source of truth is a moving target. When building out a design system, you might start with a master file with some nice documentation and a well-defined system of symbols. That’s a great start, but as soon as you copy symbols from one file to another, they’re out-of-sync and can only be updated manually. Now you have to dig through all your design documents, replace symbols and update their overrides one symbol at a time any time you make a minor change.

As designers, our tools just don’t support the synchronized and compounding component structures needed to create lasting design systems.

Brad Frost’s Atomic Design

None of this is new. Design systems have been a hot topic of conversation in product design for a while now. There’s a reason the most successful design teams in the world like Facebook, Google, and Airbnb invest heavily in design systems to help their teams function more efficiently — because design tools have failed to keep up. As a result, these companies have had to build their own custom tools and hire staff whose entire job is to maintain these systems.

Airbnb’s Design Language System

Bridging the gap

Since long before I joined the team last June, Figma’s been working to create a tool that connects visual design to dynamic user interface design. So far, we’ve released:

Now, we’re releasing a beta of Team Libraries to make components usable across all of your files and team members.

Team Libraries are a perfect example of why we built Figma on the web. They let you create effective, scalable design systems by reusing shared, synchronized components across files and team members. This feature makes it easier and more efficient to build layouts with rules and structure, enabling faster design processes for a wide variety of devices and platforms. Because it’s always online, there’s effectively zero sync time across your files.

Team Libraries in Figma

Our Approach

Just as systemic design has moved from being a “nice-to-have” to becoming a requirement in product design, the composition of applications from discrete, clearly-defined parts has become more popular in engineering, via frameworks like React. The product cycle benefits globally from a clearer, more maintainable structure, so we purposely enabled designers to benefit from that workflow in Figma.

Building programming principles into a design tool isn’t cut-and-dry, though. We know that many designers think differently than their technical teammates, so we took a few engineering concepts and refined them to make them more accessible.

How it works

The core of the feature can be described in three simple steps: Publish, Insert, and Update.

1. Publish

As you’re working in a design file and iterating through the latest swath of UI concepts, you’ll inevitably come to a point where a decision needs to be made about which of the many possible solutions is The One™.

When you finally get to that point:

  1. Select the component you want to make available in the team library by clicking the “Add to Library” button in the inspector sidebar.
  2. Add as many components from the file as you like.
  3. Review your changes and publish them to your team’s library.

Separating the library from the source file allows you to manage permissions for who is able to change the source of truth for your design system. Only people with Edit permissions to the source file can modify your source components, but anyone with View access can use the published components from that file. So, now your Production Designers are the only ones who can edit the file with the final icon assets and your Brand Designers are the only group who can control your color documentation. Everyone else can use their work, but they can’t set the rules.

2. Insert

Once you’ve added your components to your team’s library, they’re available to anyone who has permission to view the source file. The shared components can be inserted in any file by clicking the components tool in the toolbar and selecting the component(s) to be inserted.

You can even nest components and publish them to the team library. That way you can construct modules from individual source elements, then later reuse those modules across more complex views and flows in other files. Deeply-nested components make maintaining a single source of truth incredibly easy and predictable.

3. Update

What happens when your brand guidelines change and assets need to be updated? Simply make the changes inside the existing component and publish it again. You’ll get a confirmation step, just like when you added them to the team library in the first place and you’ll see a nice visual diff of what changed from the last version. If you delete a component in the source file and publish those changes, you’ll see that component disappear from the team library as well, so only the current parts of your design system are shared with your team.

Being able to change a component in the team library could be problematic when the component is being used in different UI explorations, so we built in an extra step to make sure you don’t lose work. When a change is published to a component you’re using in a different file, you’ll see a notification alerting you to the update. You can choose whether or not to accept it, and if you decide not to you can update it later through the team library.


By creating a design system that is clear and rule-driven, your UI components can be built and maintained in their simplest possible form and any updates will be applied in way that is predictable and cascade throughout the rest of your system.

We’re launching this as a beta feature today because we want to get it out into the world to start honing it based on user feedback as fast as possible. You can try out Team Libraries at right now — just make a component and hit ‘Add to Library’!

We’d love to hear what you think and how we can make this even better for you and your workflow.