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.