How to structure teams in Figma

Within Figma, teams can have three types of permissions: open, closed, and secret.

Open is a fully transparent team that anyone in your organization can join at any time. This is best for most situations, and encourages an open design culture.

Closed requires a request from your colleagues before they can join, which is ideal if you want to limit who’s making updates to your designs.

Secret teams are exactly that, as they prevent your entire organization from seeing what you’re working on; only the team creator and editors have access… perfect for that surprise project you’re cooking up.

Despite being called teams, these permission types can be a great way to separate workstreams within your organization. If you don’t know where to start, try setting up teams in Figma by mirroring your product team’s structure. For example, your organization might be split into platforms, like web, iOS, and Android—all guided by an overarching design system. By allowing your different disciplines to work independently within their own Figma space, you can operate as transparently as you need. If, say, the iOS team requires the creation of a secret team while the next version of the product is being released, that can be managed independently from the rest of your Figma teams.

Teams can also be useful for larger groups that look after separate, more complex projects. At Figma, we’ve set up teams for each part of our product, like prototyping, design systems, collaboration, and so on. This encourages a workflow in which our central design system is consumed by different product teams that all share our Figma components and styles library.

Before diving into approaches, it’s helpful to think about what the “day to day” of a designer on your team looks like. Can they achieve most of their responsibilities in one or two teams within Figma? Would a new designer joining the team be able to understand your Figma structure at a glance, or would it require training?

Simplicity is your friend here.

Within your organization, create a separate team for your design system—or set of Figma libraries—with its own unique project, file, and permissions structure. Splitting it out into a separate team can help you frame it as a distinct workstream, handled independently by a subset of the team. If you'd like a simple structure to get started, check out this community file; this one is more in-depth.

A separate team allows you to manage individual edit and view access on the work inside of your design system, whether that’s at the team, project, file, or even branch level. This extra layer of organization gives you the flexibility to use projects for organizing your system, too. Once you create a separate team for your design system, there are four different approaches to choose from.

Note: It’s still possible for different teams to use different design systems. Take a look at our help center article covering library permissions.

By lines of business

Structuring teams by lines of business is best for umbrella companies where designers are responsible for particular products

For larger companies with a portfolio of sub-businesses or products, creating teams for each is the way to go. This approach will allow you to manage permissions for specific lines of business, with the flexibility of inviting stakeholders into multiple teams (or projects within teams) as needed.

For example, a company like Alphabet might want to create a different team within Figma for each of their businesses, say, Google Maps, Gmail, and Search. By mapping the structure to each area of their business, designers can be responsible for delivering work specific to their own workstreams, create libraries unique to the style of their team, and invite key stakeholders to the correct areas of Figma.

As you can imagine, at this scale, you may end up needing to split your work down even further to stay on top of all the features you’re designing. This is where prefixes come in handy. For example, by adding iOS to the start of your teams, you can more easily search within Figma and surface all the teams responsible for working specifically on this platform.

By platforms

Structuring teams by platforms is best for independent teams who work on specific operating systems

This approach is best if you’re a design team that typically focuses on one platform. Or, if your engineering team is split into platform-specific groups, you may organically land here as you map designs to team structure.

Start by creating an individual team for each operating system, like iOS, Android, and web. If you have multiple apps or websites, those should be separate teams as well. This approach allows you to group those systems into very intentional project work and keep everything siloed just enough so that new team members and stakeholders can quickly see how the work maps to product.

Like the previous approach, if you need to create smaller teams within this structure, you can prefix them with a name to aid discoverability. If you work in a large product team where each platform is split into multiple workstreams, products, or features, you might consider creating “sub” teams. In this instance, you’d use a platform prefix on team names, followed by the product feature that your team is working on to make sure that they are easily discoverable via Figma search.

By initiatives

Structuring teams by initiatives is best for product teams grouped by feature

Initiatives are similar to the popular “squad model,” which is based on cross-functional product teams. (The Spotify team created an excellent Figma Community file that takes you through their entire process using this model, and I highly recommend a read.) If you’re working within an agile project, it functions just like a large feature or epic.

For teams that work on long projects—like consultancies, agencies, or annual release software products—you’ll probably be spending time in one Figma space for six to twelve months at a time. This requires an approach that’s semi-permanent, while flexible enough to be situated within a larger product team and organization.

If this is you, map teams to your internal epics or long-term initiatives. Perhaps you’re embarking on a major onboarding feature release that will significantly impact the user flow—this would be a perfect time to create a team. Or, say you’re introducing a notifications feature to your app—this would warrant an approach that’s larger than a team for an individual feature, but smaller than one for a platform or operating system.

As you can imagine, this approach involves creating more teams as your products mature, which will require governance from an admin perspective. If this is the case, align team names to the nomenclature that you use across the business for each area of the product, abbreviating them as needed. For example, in the team name, “Checkout” would be “Checkout,” “Product Landing Page (PLP)” would be “PLP,” and “Growth Marketing” could be consolidated to “Growth,” to make team names as scannable as possible. This is a good opportunity to align across the product and design teams to ensure everyone is aware of the correct naming conventions.

This approach is ideal for globally-distributed teams, with work that can be split down to building block, feature level. On the surface, admins can track the features that designers are actively working on as they transition through the design pipeline, with visibility over each release. Additionally, with this approach you may find it easier to track a designer’s allocation from your Figma admin panel. Is one designer working across multiple teams at the same time? They might be stretched and need help!

By pillars

Structuring teams by pillars is best for companies with distinct features that fall under one product offering

This approach is how we at Figma structure our teams! It’s great for companies that build and hire for specific feature development. For example, a cross-functional working group built branching in Figma, so we have a dedicated team for that pillar. Similarly, our prototyping team has their own space within Figma to work on new feature updates.

This differs from the lines of business approach in that this method isn’t for separate products that are sold independently; it works for teams that still fall under the same product offering. If you’re billing separately for your individual product areas, it may make sense to look at the guidance around adding prefixes.

By scale

How you structure your team should depend on the size and scale of your organization

While there’s nothing stopping you from inviting 100 editors into a team, that could cause issues with keeping your work consistently organized and structured, and flowing through the design process. Creating smaller teams that are responsible for specific areas of the product allows you to be more nimble, while setting a strong foundation as you scale.

How many editors should a team have? Try to think about editors as you would guests around a dinner table. Just as there’s a limit to how many people would comfortably be able to contribute to a dinner party conversation around one table, there are only so many designers who can seamlessly contribute to a piece of design as editors within Figma.

Similarly, it might be useful to follow the Jeff Bezos “two pizza rule” when it comes to team size. Would two pizzas be sufficient to feed the editors on your team? If the answer is no, break the team up into smaller ones.

While you should be thoughtful about the number of editors in your team, be liberal about adding viewers—there's no limit on those, and having them fosters an open and transparent design culture. That might mean inviting all of your designers to your design system team as viewers, so they can take a look at library files when they need to, rather than requesting access each time they view a component. Think about including developers and other design-adjacent colleagues too, the more the merrier when it comes to viewing our design work.

If you’d like to plan your own team structure, we have a FigJam template to get you started.