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 would have been interested in the future of interfaces... but it looks like whoever created this page still needs to master the interfaces of the present. I have no idea why a ragged-right text layout would have such wonky-sized spaces... And the broken English doesn't help. If it's THAT important, you should at least have it proof read...

https://zeroheight.com/ Looks like a great product. I've been testing it with our UI Kit, and am happy with the results... so far. It seems to play nice with solutions that are catered to design or development teams.

Atomic.io never really caught on, I feel like... but I've found it to be a comparable alternative to Principal, and for everything I've used it for I've been able to get away with the free plan. It allows for variables and form fields, complex interactions and components... I usually have specific tools to address the spectrum of complexity that I need to communicate in a specific project. Sometimes that's wireframes, some times it's simply high fidelity mockups, then low fidelity prototypes, more complex interactions, to high fidelity prototypes to fully functional prototypes that just aren't hooked up on the back end... following that same flow, my tools would be Invision Freehand, Sketch, Invision, Principal, Atomic, Webflow. Beyond that, I'm handing it off to development...