How I organise and structure my Figma files
I've been thinking about this for a while, and I'm not sure I've fully figured it out. But I've been designing for fourteen years and using Figma for the better part of the last seven, and at some point the way I organise my files stopped changing. That probably means something.
The thing is, a Figma file is a design tool, but it's also the thing your client opens when you're not in the room. The structure says something about how you think. I've watched clients form opinions about a project before they've scrolled past the first page, just from how the sidebar looked. Messy sidebar, neat work? They remember the sidebar.
So here's how I do it. Some of it is deliberate. Some of it is just what stuck after years of trying other things that didn't.
The short version
I structure every Figma file as a linear story. Pages are chapters. Frames are paragraphs. The file opens on a cover page and ends on a handoff page. If someone clicks through it in order, they should be able to understand the project without me explaining anything.
That's it. The rest is just implementation.
Why I think this matters more than people assume
Figma's own guide on team file organisation talks about findability and collaboration at scale. That's true for product teams. But I'm a freelancer, so the stakes are different.
When a client opens your Figma link, they're already forming an opinion. Scattered frames, page names like 'Page 1', a cover that's just a blank artboard. It all says the same thing: this person is making it up as they go. The opposite works too. A file that reads like a book tells the client you've been here before. You know where this is going, even if you're still figuring out the details.
There's also the version of you that opens this file six months later. A developer needs to grab the logo assets, or you need to extend the project. If a stranger can follow it, future you can follow it. Future you will be grateful. Present you doesn't care. That's normal.
| Page | What it's for |
|---|---|
| 00. Cover | Project name, client, date, status, table of contents |
| 01. Brief | Scope, goals, audience, constraints, deadlines |
| 02. Research | Moodboards, competitor work, inspiration, references |
| 03. Explorations | Early directions, wide and rough |
| 04. Refinement | Selected direction, tightened and developed |
| 05. Final | Approved designs, signed off |
| 06. Applications | Designs shown in context (mockups, real-world usage) |
| 07. Handoff | Export-ready assets, naming, file list for developer or client |
| 08. Archive | Old versions, discarded directions, scraps |
| 09. Styles & Components | Type styles, colour styles, reusable components |
Every page starts with '00' through '09' so they sort in order. The numbers matter more than the names. I could rename 'Explorations' to 'Ideas' tomorrow and nothing would break.
Page by page
00. Cover
The cover page is the first thing the client sees. It should look like the cover of a book, not a terms and conditions page.
What I put on mine: client name, project name, date of last update, a status label (In progress, Ready for review, Final), a short table of contents with page numbers, and my contact details. That's it. No gradient backgrounds. No stock imagery. If the cover feels premature at the start of the project, I leave it sparse and update it as the work develops.
01. Brief
This is where I paste the project brief. Scope, goals, target audience, deadlines, budget, constraints. Whatever was agreed in the kickoff call.
Having it inside the Figma file sounds redundant. It's not. Every time a client pushes the work in a new direction mid-project, I can scroll back to this page and point at what we agreed. It saves the awkward pause where both of us pretend to check our notes.
02. Research
Moodboards, competitor work, typographic references, screenshots of UI patterns I want to borrow from, photographs, things that feel right, things that feel wrong. I organise this as a grid, grouped by theme, with short captions underneath each cluster.
The goal is that a client can scroll through this page and understand the aesthetic territory without me presenting it. Sometimes they see something here and say 'yes, that, more of that', which is more useful than any brief paragraph I could write.
03. Explorations
This is the messy page. Early sketches, rough directions, quick typographic treatments, layout tests. I let this page be ugly. I work fast here and throw things away without thinking too hard about it.
I usually show this page to the client in the first big review. Not because the work is good yet, but because clients tend to underestimate the amount of thinking behind the decisions they're about to judge. Showing the breadth of exploration earns trust. It says 'I tried forty things and I'm showing you the three that worked', which is a very different conversation from 'here's what I came up with'.
04. Refinement
Once we pick a direction, this page is where it gets developed. Refined logo variants, extended type systems, tightened layouts, colour palettes narrowed down, interaction states taking shape.
This page moves fastest during the middle of a project. I'm rearranging frames, duplicating things, killing ideas. The structure needs to make it easy to do that without breaking anything upstream or downstream. It mostly does. When it doesn't, I notice.
05. Final
The approved, signed-off work. For a brand project: identity system, logos, lockups, palette, type system, usage rules. For a UI project: final screens with every state documented. For motion: locked frames before animation.
Nothing that isn't final lives on this page. I think of it as the one a new team member should open if they need to answer the question 'what does the finished work look like?'. If it's there, it's done.
06. Applications
Logo on a business card. UI screen on a real device. Type system on a web banner. Colour palette on packaging. This page puts the work in context.
It also breaks it. Showing a design in context is how you find out it falls apart at small sizes or on a dark background. Better to discover that here than after launch. I've caught things on this page that I missed after staring at the design for three weeks on a white artboard.
07. Handoff
This is the page I send developers to. Export-ready files, correctly named. Colour palette with hex, RGB, and CMYK values. Font names, weights, and licences. Asset naming conventions. For UI work, I add a components section with interaction notes and spacing tokens.
This page is a receipt. It's what a client forwards to the next vendor, and it's what saves me from a year of 'can you send me that file again' emails. I used to dread handoff. Now it's close to instant because I've been building it as I go.
08. Archive
Anything I kill but don't want to lose. Old directions, earlier colour systems, abandoned type pairings, layout experiments that went nowhere. I drag them here and leave them alone.
Archive pages get ugly. That's fine. The point isn't to impress anyone. It's to make sure I never permanently delete something I might want to rescue three weeks later. I've rescued things from this page more often than I'd like to admit.
09. Styles and components
This is where I build the atomic pieces of the file. Type styles named consistently. Colour styles the same way. Components I can drop anywhere in the file and update from one place.
If I had to pick one habit that has saved me the most time in Figma, it's this: build styles and components early, even on small projects. The moment a client says 'can we try a slightly warmer version of that beige?', you either change it in one place or in forty. I've done it both ways. One of them ruins your afternoon.
Naming conventions
Layer names in Figma rot fast. If you don't pay attention, you end up with a file full of 'Rectangle 42', 'Group 18', and 'Frame 203'. When you're presenting to a client, layer names appear in the sidebar. They're part of the experience whether you want them to be or not.
My rules:
Pages start with a number. 00. Cover, 01. Brief, and so on.
Frames inside a page are numbered too. 01. Logo Primary, 02. Home Screen.
I rename any group or frame I'll reference later. Small utility groups that nobody will ever look at, I leave alone.
Colour styles are named by role, not by hex. Brand / Primary, Brand / Accent, Neutral / Dark.
Type styles are named by role too. Display / Large, Body / Regular, not Inter 48 Bold.
The last two sound minor but they're not. Role-based naming means I can swap the typeface or hex value later without renaming anything. That's the difference between a late-stage revision taking five minutes and taking your whole evening.
One file or many?
For most projects, I keep everything in one file. Multiple pages inside one file, not multiple files inside one project. The reason is simple: clients get confused when they have to click back to the project view and open a different file. Scrolling across pages inside a file feels more like flipping through a book, which is closer to how the work actually progresses.
There are exceptions. If the scope includes both an identity and a website, the website usually gets its own file. UI projects with dozens of screens sometimes get split by product area. But the default is one file, organised well. That still beats five files labelled 'final v3 FINAL actually final.fig'.
Does this save time?
People ask whether this much structure is overkill for a small project. The honest answer: it pays itself back almost immediately.
Client reviews move faster because I don't have to explain where anything is. The file becomes its own walkthrough, and the conversation stays on the work instead of the navigation. Revision rounds are cleaner because styles and components are set up early, so a colour change happens once. Handoff is close to instant because I've been building it delivery-ready the whole time.
I'd guess this saves me a day or two per project. On ten projects a year, that's a couple of weeks back. I'll take it.
Questions people actually ask me
How long does this take to set up? Twenty minutes, maybe ten from a template. That's nothing. You'll spend longer than that searching for 'that frame I made last week' in a file with no structure.
Does this work for UI as well as brand? Yes. The pages mean slightly different things (Applications is a device mockup for UI, a business card for brand) but the spine holds.
Do I really need a cover page? I get this one a lot. Yes. First impressions are cheap to make and expensive to recover from.
Should I delete old pages when the project ends? No. Archive them. You will want to look at a killed direction again, guaranteed. And you'll want to remember why you killed it.
What if my client wants to edit the file? View link. Always. Edit access is how pages get deleted at 11pm and you wake up to an email that starts with 'I think I broke something'.
The template
I've turned this structure into a free Figma template you can duplicate and use on your next project, whatever you're designing. It includes the cover page, all nine structured pages, placeholder styles, and a handful of named components to get you started.
If you want it, grab it here: Download the free Figma project template. No email gate, no upsell. Just the file I wish someone had handed me on my first project.
The thing I keep coming back to
I know designers who do better work than me but whose files look like they were assembled during a power cut. Their clients never see the quality, because the file already told a different story before anyone looked at the design. That frustrates me on their behalf.
Structure won't make bad work good. But it will stop good work from looking careless. And careless is what clients remember.
If you're starting a project this week, try the numbered pages. It's the smallest thing on this list. It might be the one that matters most.
Working on something? I'm taking on new projects. Book a free 30-minute call or start a project.
