Best practices: How to structure your files in Figma

Understanding Teams, Projects, Files and Pages

Figma has slowly become the most popular Design Software choice especially for large and/or mostly remote Design teams (so the vast majority). Its features support sketching, iterating and whiteboard practices, feedback collection and collaboration, version control, wireframing in all fidelities, mature prototyping and testing, and a smooth handoff. In short: Not only can Figma support the entire design process end-to-end, but it delivers additional that we didn’t even knew we needed. One important factor for many teams is the way Figma seems (and is) highly accessible to any team member or external stakeholders, even non-designers who haven’t spent time immersing in the design process or studying the software.
This is due to the way Figma allows to structure design content in several clear layers (Teams, Projects, Files, Pages). If done right, it will never feel messy, cluttered or confusing and even external visitors can find their way around! So how to best structure any new or existing design material? Here are a few handy notes to understand how to best structure your design material.

Who this article is for
Is your team transitioning from other Software to Figma? Are you new to Figma? Are you not entirely sold on your file structure? Are you confused about what should be a project and what should be a file, or what the key difference between files and pages is? Read on.

1) Teams

This one is easy. Your team is you plus the people you work with on the same kind of stuff. You can always add members to the team, or share an “only view” access link, or provide “edit” access to anyone else you’d like to get involved. Inside a team’s workspace, you can create multiple projects.

2) Projects

What types of things should be my projects?

• Different clients can be different projects.
• Different products can be be different projects.
• Resources such as brand assets, templates, presentations and slide decks, external files, etc. can be projects.
• Component libraries and design systems can be projects.
• You can have the development of a certain feature be a project.
• External files for usability testing, tutorials, or shared resources can be projects.

It really depends on what feels intuitive to your team and what your needs are. The best practise in this case is what’s usable for the people who use it, and scaleable for the company. Think about how your content will grow and what sub-pieces of content you’ll need! A project can contain multiple files. So if you have multiple design systems, why not create a project “Design Systems” with multiple files inside. If you only have one design system per product, but are working on multiple products, consider naming your projects after your products instead, and creating files inside those named “Design System”.

3) Files

Inside a project, you’ll find all the design files that belong to this project. Design files can also “lie around loose”, without being stored in any project. In this case, you’ll find them on your Dashbaord under “recent” or “drafts” or by searching.

A design file is what’s represented by a thumbnail and a title on your Figma dashboard. A design file has several pages inside it. The layer styles you define for a file are effective for all pages inside a design file, which means they’re accessible from all pages and are used by default. Editing a style in one page of the file changes it for the entire file. If you want to use an entirely different design style for a new iteration, such as new colours, texts, shape styles etc., it might make more sense to create a new design file!
Imagine you create some wireframes for my company, following the visual guidelines of a previously engaged design agency. After a couple of weeks, you get the commission to create a new brand language. As you’ll change all sorts of layer styles, you will make a copy of the file, rename it to “Redesign 11–2021” and make your changes in there. Not only can you leverage your new styles this way and use them consistently throughout the file — the rest of the team, including development, can also easily understand and find them without you writing out instructions and running around collecting HEX codes.

This is what a file looks like once opened — on the left you can see a list of all the pages. On the right you can see the layer styles that were set. They now apply to all the pages in this file.

Pages

There are several ways to use Pages in Figma.

• Version Control
  You can use them to keep track of different versions of your work. There is another way to do version control in Figma by now, but if this feels easy and clear to you, why not copy your page at a milestone, rename the new page accordingly and start working in the copy? You can then easily refer back to design solutions you had implemented earlier. You can even have a page in which feedback workshops or design critique is displayed.
• Design Process States
  Your team might have a workflow in which your designs go through a certain process, maybe one team member ideates and hands over to someone else to provide feedback, who hands them over to someone for refinement, who hands them over to someone for final approval, or something among those lines. “Ideation”-frames might not want to live in the same space as “Ready-for-dev”-frames. It might make sense to use different pages to make that distinction!
• Components Page
  You can create a dedicated Components page, in which your main components have their home. You should then make it a habit to move all your main components to that page!
• You can use them to show various flows.
  The frames you create in different processes can be very numerous and it might be hard (especially for external stakeholders) to find their way around a specific user flow. Why not extract the frames that are part of a specific user flow and paste them into a dedicated page with an obvious name, such as “User Flow: Create Account”? The prototype for this flow can be found in just a few clicks.
• Spacer Pages
  You can create empty pages without any content, which you just use to enhance your page navigation. You’re purely inserting the page name, using spacers or content titles. This way, you have a real “Table of contents” that can make it easier to find what you’re looking for! With this hack, it’s also easier to mix-and-match several of the above listed page organisation techniques. For example, you could have a section called “Previous Versions”, a section called “Design Process”, a section called “User Flows”, and a Section called “Documentation”.

Spacer Page (___) and Content Title Page (DRAFTS) — these don’t have any actual content and purely serve a better navigation through the file.

Let me know how these practices work for you! Do you have any additional tips, or ways to organise even more effectively? Feel free to reach out and I will happily edit. It’s always a win to me to build the blueprint and setup of something in the most efficient way. It will pay off 1000 times later on! The less time spent on the search for assets and specific frames, the more free time to (input your answer*).

*For me: eating salty rice dishes that make you want to drink tons of water, collecting things from the street and claiming they are artistic, or using hair masks.