In Figma Organization you can create an unlimited number of teams, which gives you an additional level of control over file organization and user permissions. It's important to think through your team set-up carefully, because this configuration will impact the level of access and user permissions to files within each team. A team can have its own projects, documents, and shared libraries, as well as be configured to have different levels of visibility within Figma. Shared libraries can be enabled by default for each team, or even for the entire organization, accessible to everyone, which may be another consideration when figuring out how to structure your teams.
This guide will help you identify the best approach for your company. We'll cover: 1. Visibility of teams 2. Strategies for team creation: For collaboration, permissions, and file management; for design systems; for agencies
When you create a new team, the first thing to define, aside from its name, is its type. There are three to choose from: Open, Closed and Secret. This setting will define what level of visibility and access each team has within your organization's Figma account.
Visibility: Everyone within your organization can see the "open" team listed, join it, and see all of the projects or documents inside.
Permissions: Members who choose to join an open team will be given view access (with the ability to comment, inspect and export assets) by default so they can't accidentally edit something. Team admins can grant edit access to the team to individual people as necessary.
Good for: Companies that want to foster a highly collaborative environment. When people have a window into what other teams are working on, they have the opportunity to work more cross-functionally and they can maintain consistent patterns across different products or projects.
Visibility: Everyone in the organization can see that the "closed" team exists from the "View all teams" modal, but non-members will not be able to immediately see or join the projects and documents inside.
Permissions: Users who wish to join a closed team need to request access to see projects. Team admins can permit or deny these requests and give the users the appropriate amount of access (view or edit).
Good for: This type will be best suited for teams who can't share their work with the entire organization, but can still benefit from everyone knowing about their existence. This gives people a destination to go if they do require access.
Visibility: No one can see that a "secret" team exists within the Figma organization, unless they are the creator or have been specifically invited to join.
Permissions: Owners of secret teams need to individually invite the members they want to have access. They can also set the appropriate view or edit permissions for each user.
Good for: This is great for top secret projects that only a very specific subset of users require access to. Think of work done leading up to an acquisition or something that cannot have org-wide knowledge. This access type can be changed at any point to give these teams more visibility when the timing is right.
Now that you've decided on whether individual teams are open, closed, or secret, you'll also need to decide how to organize your overall team structure. Should your Figma teams mirror the actual departments in your organization, or something else? Where should your design system live, or how should you handle client files if you're at an agency?
These decisions will vary greatly depending on your company's culture and needs. There's a few different ways to approach this, and there is a good chance you'll combine some of these ideas into a structure that works for your organization.
Remember: User permissions are handled at the team level and cascade down through all projects and documents within it. The MOST important thing to be aware of is that if people join a team with edit access, they will be automatically able to edit ALL projects and files in it. So, in setting up your teams, think carefully about who you want to have that edit permission.
Overview: You structure teams in Figma based on the actual teams and departments in your organization. These could be as broad as marketing, user experience and visual design, or might be centered around different products, depending on how your company organizes itself internally.
Good for: If you're a very large enterprise with thousands of employees and offices across the globe, it might make sense to keep different parts of the company centralized in their own teams so that it's easier to collaborate on initiatives that involve the entire team.
Permissions: Beware — by making a team for a large department, you're also centralizing all the permissions for that team. So, lets say you make a 'marketing' team and your brand designers create landing pages in it. Anyone who's an editor on the marketing team, from copy-editors to product marketers, will be able to edit the designers' work. If you need more control of edit permissions, consider the next approach.
Overview: You structure teams around specific efforts in your company. This could be a group of people cross-functionally working on a specific product, project or initiative, from designers to copywriters to PM's.
Analogy: This is similar to how most companies set up their channels in Slack where many users are members of multiple channels.
Good for: When you structure teams around efforts, it makes it easier for people from different parts of the organization to collaborate together on that effort with the appropriate amount of access.
Permissions: By structuring teams around efforts, you can have tighter, more specific control of user permissions. For example, if a group of 10 people are working on a new effort, by creating a team just for them, you can isolate edit access to just those users.
As you explore the concept of a team to be used for a specific effort, consider how projects in Figma can serve as organizational subdirectories for your files. Here are a few ways we've seen projects being used — almost like a folder — to organize files within a team.
Projects to organize different stages of the project Example: Explorations, Wireframes, Hi-fidelity, Ready for development
Projects to organize design for different parts of your product Example: Login/User creation, Dashboards, Design for a specific flow/feature
Projects to organize design for different scales Example: Mobile/Tablet (Small/Medium), Desktop (Large)
Overview: If you have components and styles that various teams within your organization need to use, you may consider setting up a dedicated team to share the libraries from. That way, you can more tightly control edit access (which comes with the ability to publish) updates to the libraries. The editor(s) on this team could be the specific designer who maintains the libraries or a dedicated design systems team.
Good for: Giving all users a clear destination where they can find and explore the latest component and style libraries. Some teams may even choose to arrange text, examples, and additional usage documentation alongside their master components within these shared libraries
Visibility: We generally recommend you make this team open. That way, everyone in the organization can see the libraries which are available to them (but not necessarily have the ability to edit). When these libraries are easy to find and are highly visible, they are more likely to get used.
Once you have started building your shared libraries and have situated them in a team with the appropriate level of access, you can start thinking about enabling certain libraries by default for the entire company, or specific libraries for specific teams.
Overview: When these libraries are turned on at the organization level, every document created, regardless of team, will automatically enable have the specified libraries enabled. Users that navigate to the components panel will see it pre-populated with components from those libraries. Libraries can also be enabled at the team level as well, so any document created within a specific team can have additional libraries turned on which are useful or specific to that team.
Example: You have teams working on desktop and mobile products, but perhaps you also have some brand assets and colors which are shared across those teams. You might decide to break these into multiple files and publish separate three libraries for ease of sharing. This way you could make your brand assets and colors a default library for the entire org, but only enable the mobile and desktop libraries for the specific teams working on mobile or desktop products.
Good for: Ensuring users have the correct libraries enabled and are using the latest components. This also helps onboard new users to Figma, since they don't have to hunt down where the latest libraries are and can hit the ground running.
Overview: If you have a team of people dedicated to creating, maintaining and distributing the company's design system, we recommend giving them their own specific Figma team for their work in progress, separate from the team where they house the published libraries they are in charge of maintaining and distributing.
Good for: Avoiding confusion about where the source of truth is for the design system. The design systems team can be free to do explorations, review component/pattern proposals and perform audits on existing patterns without any impact to users.
Visibility: You may consider making this team closed to avoid any confusion with the ready-to-use components.
Overview: If you are working with clients, it may make sense to create a team for each of them within your organization.
Good for: Creating client-specific libraries with their colors, brand assets, and components, and enabling these libraries, in addition to shared fonts (if they have a brand/corporate font) as defaults for the team.
Visibility: It may make sense to set these up as closed teams, especially if you have dedicated designers assigned to specific clients and need to keep sensitive work confined to those users for IP reasons.
Avatars: Create an avatar or profile image for your organization and your individual teams to make them more identifiable. Cover pages: Create cover pages for your docs to customize the thumbnails in the file browser. You can do this by creating a design of the first page in any document. Here is a link to a Figma file to get you started. Permissions at team level: When you need to share work with collaborators, consider granting them access at the team level if appropriate. You can always add collaborators to specific documents, but if you need to revoke access, it will be much easier to manage your list of users and their permissions at the team level, instead of remembering which specific files you invited them to.
We hope these considerations help you effectively set up teams within your organization. As a recap, consider the following as you start creating teams:
As always, if you want to connect with other Figma users and learn how they are setting up their organizations, be sure to join our community on Spectrum.