Best practices for managing file organization in Figma

Once your teams and projects are set up for success, you can create a file structure that’ll make your design process feel as smooth as butter. That’s one step closer to the fun part—actually designing interfaces in Figma.

To recap: Within teams, there are projects, and within projects, there are files. Similar to teams and projects, you have the ability to create an unlimited amount of files within the Professional, Organization, and Enterprise plans, so go wild!

This freedom means a lot of flexibility, which is why a robust file structure that’s consistent across your organization can help you ship products faster. Since files aren’t tied to individual projects, you can drag and drop them into any project, which is useful if you want to match them to a workflow-based project structure.

Size

When teams migrate to Figma, many of them have one file that includes the entire design process, with multiple iterations and versions. While it’s tempting (and often convenient) to include an entire product within one file, try to keep files as small and nimble as possible. There are of course exceptions to the rule, though! If this is your workflow and you have a larger file, make sure to create a new file or branch for every feature update. This way, you can focus on the work at hand, rather than being confused by other, older design work that doesn't require an iterative update.

While you have your main user flow in one file, and iterative updates in others (or a branch), it makes sense to introduce a process whereby this newer work is “merged” back into the main flow. In order to maintain consistency and efficiency, this makes sense as a collective process either once per month, or once per quarter if you have a larger team with lots of moving parts. This larger file (or files) should live in a separate project, and you can then move smaller files into an Archive project to keep file management as clean as possible, as we covered in the projects section.

If you’re looking to archive work within files that have a longer shelf life, check out this workflow.

Naming

Who remembers the days of Account–Auth–v3.01–final2–copy-edits.png? It still gives me nightmares today.

When it comes to naming, there’s nothing wrong with being descriptive—if it’s easier to find, it’s easier to design. A descriptive name, just like a semantically named component, significantly aids the discoverability of our work. It’s just a matter of establishing a clear, repeatable naming convention, so you avoid verbose (and difficult to maintain) file names.

Depending on which project structure you opt for, a strong naming convention could look something like this for a web project:

And here’s how that may look for a software product. For example, Figma!

Files pair really nicely with our projects, so you can extend the naming to make them easier to find and understand.

Pro-tip: There’s a very neat feature within file names whereby if you type a hyphen (–) followed by an arrow (>) it automatically turns into an arrow (→). Cool, huh? It even works backwards, in case you need your arrow to point left!

If you manage your designs with project management software, you may want to follow a ticketing system with your Figma files, too. With this in mind, you could compose Figma file names that align as well. For example, a file (or branch!) named TWIG-812 – Form fields A/B test to match the task name.

Or you might work with a combination of the two! Following the feature or production state approach, you could end up with file names that are different depending on whether they are "Production" or "Feature" files, as demonstrated here:

Of course, you can introduce branching to manage versioning. Instead of using different files for new iterative updates, you can create these in a branch instead, which would align to the product surface approach:

Version history

Since Figma is built in the browser, versions are automatically created within the version history of every file. You can supercharge this by making use of “named versions” to indicate any significant changes to the team.

Being able to name major changes makes it easier to articulate the evolution of a design to stakeholders. Plus, you can restore to earlier points in time as needed.

Structure

Generally speaking, you should optimize your design files for speed, comprehension, and collaboration. This means that if you spot an opportunity to split files into smaller, more nimble ones, go ahead!

Here are a couple examples:

1. If you usually carry out a lot of image-heavy research, keep this inside a separate file. Use the same naming convention for your main file, but append it with “– Research.” For example, Account → Onboarding as the main file name, and Account → Onboarding – Research as your research file. The performance gains from smaller, more nimble files will be noticeable, and you’ll thank yourself months later when you aren’t forced to navigate a complex file with little context.
2. If your discovery work is ordinarily loose and made up of components, shapes and text, keep it all inside one file on a separate page. Name this page Discovery to keep things simple. As you progress through the design process, you might move these components to a page within the file called Components, or (even better) to the main design libraries inside your design systems team.

Let’s get into the page structures. I’ll be working on the assumption here that you’re part of #2 above.

The page structure of dreams consists of:

• Cover: Where you keep the thumbnail of your file so that it’s discoverable in the file browser.
• Visual research: A home for all those wonderful screenshots you use as inspiration.
• User research: An optional space for user testing flows and concepts.
• Discovery: Where you flesh out ideas and store your (amazing!) rejected ideas.
• Flow: How you pull together formalized ideas into a structured user flow for feedback.
• Prototype: An optional page showing micro interactions and click-throughs of work. Why is there a separate page for flow and prototype? Prototypes typically require duplications of screens for animations (a series of screens for your loader, for example) and that could be confusing to stakeholders. Keeping things separate helps you be more intentional with file organization.
• Local components: A page including components specific to this file (e.g. a carousel that’s only used on this individual screen). Knowing that you should keep components at a more global, design systems level, this page is optional unless you do need components specific to this piece of work.
• Ready for development: Once you’ve gotten sign-off from key stakeholders, organize your work here. It’s good practice to keep everything that has been signed off and shipped in a separate location from work in progress files—you don’t want to use the wrong asset in production!

If you want to uplevel your page structure, you can even include spacer pages in your side panel so that there’s a clearer distinction between phases. These are created using a series of hyphens in the name of the page–simple, but effective!

Wait, wait, wait. Where are the emojis? Let’s jazz this thing up.

As this is just a guide, your page skeleton may differ significantly, and that’s totally okay. Every company is different, and you may end up with a smaller or larger base structure for your organization.

Branching

Branching can make file management a lot easier in the long run, and ensure that you’re all working within the correct “main” file at all times.

An example may help here!

Let’s say you have a team for your consumer app, a project for the Account section of your app, and a file for the Account → Auth designs. If you need to work on a new feature like Add new form fields to the authentication flow, you could use branches to manage the design updates.

If one designer is responsible for each feature, you could create a branch for each distinct update, managed independently. For example, in this instance you’d create a branch named TWIG-812 → Form fields. TWIG-812 refers to the ticket number from your project management software, like Jira, Asana, Notion, Monday.com, Linear, and so on. You can see a full list of Figma integrations here.

Each designer would work within their own branch, testing out their ideas, gathering feedback, creating prototypes, and ultimately pushing it through the development process. You could invite your developers into a branch as viewers, or even embed the branch into your project management software to browse.

Once the work has been signed off and coded up, you’d then merge your work back into the main Account → Auth file, add a named version into the version history with a date and description of the work completed, and move onto the next feature.

Cover pages

Cover images are great for making files for discoverable. You can design these however you wish, but keeping a consistent structure is key.

To set up a cover image, create a new Frame on the canvas using the Plugin / file cover preset in our Figma Community section, illustrated below.

Once you’ve added a cover frame, you can design it! At the very least, it makes sense to include details like the file name, and a short description of its contents.

Extending this, you might include a screenshot of the work inside the file. This can help if you have lots of files with similar names.

Some teams even indicate the status of their design work and information on the team that’s designing the feature too!

There are endless options here, and you can add as much as you need to keep teammates and stakeholders informed. For inspiration, take a look at the Figma Community.

Frame organization

Good file organization is not only helpful for stakeholders, but for the wonderful developers who will build your ideas. With a few components to help organize your top level distinct user flows—and individual frames within this flow—you can quickly assemble clear, discoverable files. Looking for a jumping off point? Here’s a template to get you started.

This step is best left to the end of your design process, once everyone is on board with the direction and you’re moving towards production. Tackling this earlier might mean that you have to re-organize each time you iterate, which can be messy and frustrating. This would also happen in your Ready for development page.

Flows for different platforms

If you’re a cross functional team who ships designs for iOS, Android, and web, you’re probably wondering how best to manage this within your file. The best approach is to use the Figma canvas to organize frames according to flow. Whether it’s in prototype form, or in your Ready for development page, some simple organization tricks can make this all a lot easier to digest. In this instance, you might end up with something that looks like the following diagram.

You can see in this screenshot that frames are organized by platform, with mobile at the top and desktop underneath. This works best when you’re explicit with “on canvas” notes paired with consistent frame spacing notations, to make it easier to skim through and digest. You may even want to consider using Figma sections to group the platforms.

This is just an example, and you may have many more frames on the canvas to organize. If you’re entering a world where you have hundreds of frames per platform, consider splitting these into separate pages, or even separate files.

Ultimately, you might decide where platform designs live by thinking about the handoff process. Is the same developer(s) working on both mobile and web here? If yes, it makes sense to be in the same file. If not, split them up.

Layer naming

Ahh, our old enemy—the unnamed layer. Naming layers is not only the butt of many a design joke, it’s something that can divide teams and impact implementation. Seriously!

First, consider how much you need to be describing or communicating with layers in the first place. With this in mind, you’ll want to think about how well and how often you communicate with the development team within your organization.

If you’d prefer to read this layer naming guide as a Figma file, we have a resource that you can duplicate.

No layer names

Design stage: Ideating

Owner: File creator

I promise you I’m not cheating here, this is a legitimate approach for teams (or individuals) that don’t need to rely on the layers to communicate their design decisions.

This approach is either something you’d limit to the ideation phase of your design process, or go all in if you communicate your decisions in other ways—perhaps with on-canvas communication, or with other types of documentation.

We’re just having fun at this stage, so you don’t need to pay too much attention to our layer naming or structure. Because this is still very scrappy, we don’t need to be concerned about naming or even using particular elements (maybe a rectangle is fine for a button!).

Refinement

Design stage: Refining

Owner: File editors

Are you and your team preparing for sign off from your key stakeholders? This is where you should think about how easy it is for someone to digest your ideas and iterate on them. Clear layer names can really help here; call a card a card, a number a number, and a description a description. While individual designers are still owning their designs at this stage, layer names need to make sense to the rest of the team.

Aligning to code

Design stage: Ready for handoff

Owner: Design systems team

This section will be split in two, with a Block Level Modifier approach and one aligning to HTML markup.

1. Block Level Modifier

This concept borrows from engineering, and it helps you align layers to code so developers can quickly grasp how to structure their components.

2. Aligning to HTML

If you’re building a web product, it might be worthwhile to name your Figma layers based on how they’d be presented in the frontend markup that your developers will be writing.

These are technical approaches, and are best handled once your components are in the correct Figma library, in a production-ready state. Any time before, and this would require too many small-scale changes to your layer structure, potentially causing more issues than they solve in the long run.

While designs are really never "finished," follow this structure when you're heading into production. It’s an opportunity to collaborate with your developers, as there’s no better design process than an open and transparent one. Since this method requires knowledge of markup language, it’s best for a technical designer or the design systems team to take it on.

If your team isn’t closely aligned with your engineering counterparts, you might consider a different approach; the naming only really makes sense if both teams use it.

Bonus: Merging a few concepts

Design stage: Ready for handoff

Owner: Design systems team

What if we wanted to borrow something from each of these concepts? Using Figma’s component description field, you can meet these techniques in the middle and satisfy both design and engineering teams.

Like the more technical approaches, this is ideal for when you've already agreed on a component’s design and are moving it into the Figma library file. This way, you only need to set it up once, and publish it out to the wider team for usage.

With your design systems team closest to your engineering team, you can align the naming conventions, status, and any other important information with the correct engineers and then add it to your Figma component description.

Refinement is the easiest approach to scan and read for most teams, so let’s use it as a starting point.

Extending the layer names

You can document your components using the description field to add notes about usage and appropriate naming conventions. This will appear both for designers (in the properties panel) and developers (in the inspect panel).

Adding documentation to your components

Because there are tons of different ways to implement designs, you can help your engineering team by adding useful annotations onto the canvas.

Note: Manage documentation in a separate file, so that you can maintain documentation and component versions in two separate places. This way, docs are always up to date, even while you tinker on new ideas.

The below is an instance component with manually-added notes that align to HTML.

You’ve been framed

File organization might feel like a chore at first. But when collaboration is at the heart of your design process, the way we communicate to other team members—whether that’s through organization or naming—can help us work more smoothly and efficiently.

Live long and organize!