There's no shortage of opinions on how to organise Figma. New file per quarter. File per person. One giant file with a hundred pages. I've tried most of them, and I've landed on an approach that works well for teams of two to five designers - structured enough to be discoverable, loose enough not to get in the way.
Three projects, three purposes
The core idea is that different types of work have different needs, and trying to squeeze them into a single project creates friction. I split everything across three Figma projects:
- Design System - the source of truth for components and tokens
- Exploration - where live, messy design work happens
- Handoff - clean, annotated specs ready for development
Each one has a clear job. When someone asks "where's the search redesign?", the answer is hopefully obvious.
Design System
This project moves slowly and intentionally - components and tokens don't change on a whim. The files here are:
- Tokens - colour, spacing, typography, and any other raw values
- Design System - the component library itself, built from those tokens
- Email Design System - if you have one, keep it separate; email constraints are different enough that mixing it in causes confusion
One file per purpose. If you're ever doing a ground-up rebuild of the design system, that's a good reason to create a new file - Design System v2 - and work on it in parallel before cutting over. But for ongoing iteration, a single file is enough.
Pages within the design system file follow a simple rule: one page per component category. Buttons, forms, navigation, cards - each gets its own page. It keeps files fast and makes it easy for developers to find what they're looking for without scrolling through everything.
Component lifecycle - how to deprecate old components and roll out updates without breaking existing designs - is a topic in its own right. I've written about that separately here.
Exploration
This is where actual design work lives. It's understood to be messy, and that's fine - it's not where anyone goes to find finished specs.
I split this project into files by half-year: 2025-H1, 2025-H2, and so on. The reason is performance. Figma files get sluggish when they accumulate too many heavy frames, and splitting by time period keeps file size manageable without requiring you to make arbitrary decisions about what belongs where.
Within each file, pages are named with a date and a short description:
2025-03 - search redesign2025-04 - onboarding experiments2025-06 - nav restructure
That's it. No elaborate folder structure, no status labels. The file is a sandbox, not an archive.
If your team is larger or your output is high-volume, consider splitting to quarters instead of halves. The same logic applies - it's about keeping files fast and focused, not about any particular cadence of work.
Handoff
The handoff project is where finished work lives, ready for developers to build from. Unlike the exploration project, I don't split this by time period - I split it by feature area.
Files might be: Search, Checkout, Onboarding etc.
A few reasons. Developers tend to bookmark these files and come back to them repeatedly - a file called Search is a lot easier to find six months later than hunting through 2025-H2. It also reflects the reality that design and development rarely move at the same pace. You might have designed a new search filters implementation well before it ever reaches the dev queue, and when it does, you want everything in one place - not split across files from different time periods.
Within each file, pages are dated and named by release or significant change - and sometimes a project tracking code if that's part of your workflow:
2025-06 - inline filters [S-123]2025-09 - results page v2
This gives you a clear chronological record of how a feature has evolved.
The notation card
One habit I've picked up: every frame in a handoff file gets a small sticky note that links back to the relevant exploration page where alternatives were considered. A simple "explored alternatives → [link]" does two things. It pre-empts the "but have you tried..." question in design reviews by making it clear that the exploration happened. And it gives anyone curious a direct route to the reasoning without having to dig.
I sometimes add a lightweight decision log page at the front of handoff files too - a three-column table: option considered, why explored, why not progressed. It sounds like overhead, but it pays off when someone new joins the team or when a stakeholder revisits a decision six months later.
The thing that makes it work
The structure above is straightforward, but structure alone doesn't keep a Figma organisation healthy. What actually makes it work is a shared team agreement on one question: what does "ready for handoff" mean?
In practice, most of my day-to-day presenting happens straight from the exploration file. For standups or design reviews, I'll pull together a small section with copied references of what I'm walking through - but that's still very much WIP, and it lives in exploration. The handoff file only gets something when it's genuinely done: annotated, built from library components, and signed off.
Without that shared understanding, the handoff project either stays empty or quietly fills up with work-in-progress, and the whole system breaks down. It doesn't need to be a formal process - a brief team agreement on what "done" looks like is enough.
The other thing worth saying: revisit this every six months or so. What works for two designers starts to creak at five. The structure should serve the team, not the other way around.