We have almost the same process but with some differences: In our case, we design for both Web and Mobile platforms, we have only 3 main projects for this.

1. Web
2. Mobile
3. Internal

Internal is where all the libraries we use to design are, that is, our Design System, Flows, personas, etc. The other 2 explain themselves

Then each project is separated into "Features". for example, we have a Figma file called "Profile" inside this file, we put everything that has to do with the user's profile, the same for mobile.

Each file is organized according to our process on different pages:

1. Cover
2. Project Requirements (mostly it's a copy/paste from Confluence).
3. Research / Results
4. Moodboard / Wireframes
5. Flows / UI Screens
6. Prototype

We do not have a master file because we try to ensure that our developers are also in the process of designing/solving the problem. It could be said that the master page is Prototype because it is what we present once we reach the solution but our development team takes more as a reference the Flows / UI Screens page.

This is what has worked for us so far, btw we are a small team so maybe it can't work for teams of +20 people. It's all about communication and collaboration. Hope it helps.

Hi John, I find that the steps to get to the solution are the most important so I structure my files around that process. I also separate each file into a feature. Each page is its own design iteration, until we release a master design which is on its own page. That page holds all the documentation about the design.

I don't really use Figma that often, but I came across this article that I think is really helpful and worth sharing the other day, love the way how this designer organized his files: https://desktopofsamuel.com/how-to-organise-design-workflow-and-operation-in-figma

This is something that we're still working on. We needed more structure after switching from Sketch/Invision to Figma. Also our devs didn't like seeing 'everything' for a project on a figma page.

After a discovery session with the team, we decided the best way for us to move forward was to structure our files as follows:

Figma Teams

This basically represents the different design teams within our org. So marketing designers would be on a different 'team' than the UX Designers.

Figma Projects

We use this to organize our files based on the structure of the site we build. So since we are creating an ecommerce site, we have projects called "Catalog" which would contain search, PDP, PLP, etc; or "Ordering" which would include the Cart, or Checkout flow... etc

We also have a "Resources" Project that contains global libraries as well as our Global UI Kit.

Speaking of UI Kits, we're in the process of building out UI Kits for each Figma Project we have. So that anytime you're working on something with Checkout for example, you can import the Checkout UI Kit and have access to all of the components. This keeps our global UI Kit from getting bloated.

Figma Files

We create a new Figma File for each project we work on as a team. That could mean a feature, or a specific user problem we're trying to address. Usually it would tie to an 'epic' in Jira... But loosely... It's those things that a few teams are working on and it has a name around the office... we usually use that 'name' as the Title of our Figma Files so everyone knows what it is.

Figma Pages

We use Figma Pages to break out the different types of work we do for the project. So we may have a cover page (for easy identification), wireframe page, a prototype page, a components page, a master-working page, etc... But each page is labeled with emoji to show its state. Currently we only have 2 states: "✅" is ready for development, and "

I have a file.

My dev team has finally convinced me to have files.

Like any normal person, using the best page titles I can think of at the time.