Savina Valeria Savina likes working with complex systems as a product designer. She pays all her attention toward one product and its competitors to develop her product faster.

Organizing Figma files for team collaboration

7 min read 2226

Figma Logo

Organizing Figma files is critical to ensuring that everyone on a large team can work together effectively. Poor organization can quickly become cluttered, complicated, and a real problem.

Below we will consider different ways of organizing space based on the tasks on your table, the amount of work they require, and the size of the team.

I’ll also go through recommendations for organizing the internal space of your Figma files and projects.

Project Structuring in Figma

Figma’s terminology for project structure

Let’s start by clarifying Figma’s terminology. Figma has discrete meanings for these terms:

  • Teams are collections of projects in which libraries run at the default level
  • Projects are sets of files. Files mean the Figma or Figjam files in which you do most of your work
  • Pages are what you can have in your files to distinguish different areas, states, or modes of operation

Choosing a paid Figma plan for better organization

Figma has a free and a paid version. As with all programs, the paid version has many more advantages than the free version. Keeping files organized in the free version is difficult, since you practically can’t group your projects in any way except to label the projects and make a cover for quick search and convenience.

Therefore, my first tip is to consider the paid version with more features. With that in mind, we can go in depth on how to use the paid features to keep your files logically organized.

Freelance workspace organization in Figma

It’s never too late to start structuring your projects.

We always start by sorting by item type. Separate superficially first drafts, projects, system designs, illustration files, and so on.

In this way, we already have groups of files that we need to put into place.

When a designer works as a freelancer, they don’t have a permanent job or a permanent project. A freelancer can have several agencies or customers as an employer.

When you pay for your own Figma plan, you pay for each team.

Based on this, after creating a team, you create a folder called Projects, and inside these projects, you lay out your files.

Teams, Projects, and Files
This is an example of how to organize your files in a single paid Team.

If you are a freelancer with many clients, we’ll need to repeat this process. Here are the steps if there are many projects and the designer creates several teams:

  1. Teams (if not one) will be organized by the products we create
  2. Projects will be organized by product feature or feature sets — features that are in development
  3. Specifications will be within the same project on each respective team

Organizing your Figma workspace in companies

The working experience in both freelance or in-house settings can be substantially different. A primary challenge in any structure, regardless of which tool you use, resides in understanding the design process: discerning which design files are still in progress, up for updates, considered outdated, or all set up as the final product.

Each team operates on unique work standards that enhance the ease of file and project navigation for all designers. A uniform structure for every project warrants that each designer comprehends the structure. This holds true irrespective of their joining dates, empowering them to figure it out independently.

The structure for any organization, whether addressing a single product or multiple, ideally begins product-wise (with teams), pursuing a sequential division department-wise (their projects). These department divisions are usually marketing, development, animation, design, and so on.

We need to structure our Figma files so that every team can access their relevant projects. Here’s an example structure:

  • Design system
  • In progress
  • Approved
  • Not approved
  • Archive
  • Illustrations (rescore page)
  • Datasheet and onboarding
  • Inspiration

For each file you make, approved by the system requirements of your team, make a cover. From the cover, everyone can understand what is inside the file.

Apply different markings on the cover itself to make it visually distinctive, such as version updates, clear titling, and visual elements like emojis, which anybody on your team can use to make a cover even if they aren’t designers.

Elements of File
Elements that can be on the file cover.

These are some things to keep in mind for managing Figma files across your teams:

Teams will be organized by department (marketing, development, design, and so on). Projects will be organized along the lines of this department. Consider the design department, which needs a design system project, one for in progress designs, and so on. On the other hand, marketing might need projects for sales enablement materials, social media, or other use cases.

The files within the projects will be organized by their function or set of product features. Sometimes features are very expensive and require lots of assets, and in such cases, they are separated and put into the Team section. For example, say a casino site has a new game, and the casino operates in different markets: the European market and the Asian market. These should be separated out by team.

Organizing Company Files
An example of the way you organize your files in a company.

The hierarchy for structuring your information

Now that we’ve put all the files in folders (Projects) and arranged them by team, it’s time to deal with the design system for each team.

We have the basic elements that make up the files in our design system: libraries, components, and styles.


Libraries are a type of Figma file with all the components a designer can use.

Taking small freelance projects as an example, this is a UI KIT that the designer creates themself or takes from ready-made UI systems to create a product design.

Within larger companies, such systems are proportionally larger, with all the specs and all the states included. Think of a constructor that you put together and take ready-made blocks to create a new design. Sometimes new components are created and you have to develop them.

And when you use existing elements, development is faster and more efficient. Such design systems have everything from icons to entire elements, such as the appearance of the messenger field. These belong in libraries.

One Way to Organize Library
A visual representation of one way to organize your library.


Components are an element of design. Components are divided into what we can call atoms, molecules, and organisms.

We combine all the atoms into what we call variants. We do the same with molecules and organisms (e.g., default and active state, or hover and click). So by inserting one organism, we can easily choose the desired state of that organism and replace the atoms and molecules inside. Those are components.

This is how a design system is built. You always have to think about which elements you can combine with what and in which organisms they will be available. It is most difficult in CRM systems, because you have to think about which organisms should grow and what will be included in them.

And do not forget that when you design a system, you must always put the template first in the variant of the components. This is what you’ll modify in all future variants.


Styles are properties: color, fill, strokes, text, effects, and grid layouts to name a few. These are usually consistent across your projects.

Putting these together: organizing libraries

Company design systems are often very large and heavy, so it is better to divide them into several files. The easiest way to do this is to cascade your libraries, which are separate from the component library:

  • A library just for styles: colors, fonts, shadows
  • A library for different platforms: iOS, Android, Web
  • A library for different themes: light and dark modes
Cascading Library
A visual representation of the cascade library.

Not only will this speed up your design file creation and help your design team simplify iterations, but it should also make it easier to use your workspace.

File structure best practices for Figma

Now we’ve got the structure of our files and design system, so we can move directly to the files — namely, to the organization of the workspace in the file itself.

Divide large projects into pages

Always remember that it is necessary to divide large projects into pages. For example, if you create a design for several pages of the site, they should be on different pages in your files. After that, create a separate page with the final, approved options that will go live.

Dividing product pages ensures there is nothing unnecessary in front of your eyes that could be distracting.

Save often and don’t delete anything

Keep all versions of the design on a separate page. Never delete anything. Instead, create an archive.

Each edit should take place in a new frame (meaning you’ve copied the design and made edits). This is especially useful when you leave comments in the file — for example, to correct something. You copy the desired frame and make edits on the comments, and you can see both states: before and after.

Very often, you have to go back to the previous version or the one you originally did not like. Keep a hierarchy of edits and design variants in the file. Move unnecessary options to the archive, and transfer the selected frames for further edits separately.

Saving History of Corrections
Saving the history of your corrections.

Figma saves version history. If you need to restore something, it’s useful, but if you want to see one of the options that was proposed by someone else, version history won’t help you. It’s much clearer when everything is right in front of your eyes in the form of an archive.

For example, if we suddenly need to look at old solutions, it will be enough to go into the archive. There may be several different versions of the same page lying there too — we experimented, forgot, remembered after a while, and then realized that we could still use some of them for new projects.

Sign frames/layouts with big headlines

Your colleagues should be able to read text, even if you can see the whole artboard at once.

There is a new feature in Figma, sections, which allows you to select one or more elements to highlight the background and display the title (this title will be clearly visible at all scales). Before that, each team practiced different ways to label stages or frames themselves.

For example, select the stage name on a colored rectangle, information about each frame on other rectangles below, and of course, don’t forget to label each frame.

Frame Caption Options
Frame caption options.

Group your layouts

If your design implies a user path — i.e., it includes several consecutive screenshots — then they should always be put in sequence and complemented by directional arrows (from the button to the frame).

You may think this is unnecessary, but do not forget, if you are doing it, it is obvious for you, and if another designer or product manager comes along, they shouldn’t have to guess. They need to quickly understand the user’s path and see the whole way. The clearer you are as a designer, the better for the whole team.

Show screen states below or beside the main screen

If part of a frame, like a dropdown, has different states, you should put those states separately next to the frame. Then, duplicate them in the overall design.

Always clearly name the design layers

Developers have to understand your design, because you have created a visualization, and the developer needs to recreate your image for the product.

Get the illustrations right

Each illustration should be framed and rendered in curves. You can create an illustration, but then you have to translate it into curves (you have to keep both, because you cannot fix the text in curves).

The developer takes the illustration in SVG format and his illustration should not differ from yours. This illustration can easily become any size you want and always stays high quality.


There is no perfect way to organize your Figma files, and you may find a different approach that works better for your own organization, but hopefully this post has given you a few ideas to improve how you array your files.

The main conclusions from all of the above are this:

  • Keep things simple and don’t make things too complicated
  • Keep the design files separate. Always keep approved layouts separate (on the same sheet or on a separate page, depending on how Figma’s space is organized)
  • Keep your components and styles separate from your designs
  • Stick to the same naming conventions for your Figma files

Choose the right organization for you, whether you’re a freelancer, an agency, or any other complex organization. It all depends on your company and how you are organized, so you may find a different approach that is more appropriate for your organization.

LogRocket: Analytics that give you UX insights without the need for interviews

LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.

See how design choices, interactions, and issues affect your users — .

Savina Valeria Savina likes working with complex systems as a product designer. She pays all her attention toward one product and its competitors to develop her product faster.

Leave a Reply