Figma
Sign up
Figma

Getting started with teams in Figma Organization

Thomas Lowry
Thomas Lowry, Designer Advocate at Figma
Getting started with teams in Figma Organization

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

Team access types and visibility

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.

team-types
Figma Organization introduces new team access types: Open, Closed and Secret.

Open teams

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.

Closed teams

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.

Secret teams

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.

Strategies for creating teams

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.

project-vs-hierarchy
A team could represent an entire department, or a specific project.

Mapping to company's hierarchy

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.

Teams around efforts

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.

File management

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)

Design systems team to house shared libraries

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.

Setup default libraries

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.

Design Systems

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.

Design systems (work in progress) team

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.

Teams for agencies and consultancies

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.

agency-teams
Each client could have its own team, with its own shared components, styles and fonts.

A few more tips to keep tidy and easy!

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.

Customize

Wrap up

We hope these considerations help you effectively set up teams within your organization. As a recap, consider the following as you start creating teams:

  • How tightly do you need to control access to various work happening across the company?
  • How collaborative and cross-functional do you want your organization to be?
  • Who needs to have visibility into each team and the documents within it?
  • How could projects within a team help you organize your documents more effectively
  • Do libraries or fonts need to be shared across the entire company?
  • Will specific teams require certain shared libraries but not others?

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.

Try Figma for free.