Should every feature get its own Figma file?

Not every feature. Give each product area its own file, such as billing, onboarding or the dashboard, and keep features inside it as sections. One file per feature creates dozens of tiny files with duplicated components and scattered history. Split a file only when it gets slow or when two groups work on it at the same time and keep stepping on each other.

Is it better to delete old designs or archive them?

Archive them on a dedicated page with the date and the reason they were rejected. Deleting removes the context behind decisions, and someone will eventually propose the same idea again. An archive page at the end of the file keeps that history available without cluttering the pages developers use. Version history helps too, but it is much harder to browse than a labelled archive page.

How do you name Figma pages so they sort correctly?

Prefix them with two-digit numbers, such as 00 Cover, 04 Ready for dev and 99 Archive. Figma shows pages in the order you arrange them, but numbers make that order explicit, survive reordering mistakes and make it easy to point someone to a page in a message. The 99 prefix is a simple way to signal that a page holds archived work.

Do small teams need a separate Figma library file?

A team with one designer can start with a local components page inside a single working file. Move to a separate library file once the same components appear in two or more files, or once a second designer joins. At that point, copying components between files creates drift, and a published library is the cheaper way to keep everyone on the same version.

What should go on a Figma cover page?

The file name, the product area it covers, the owner, a clear status such as in progress or ready for dev, and the date it was last updated. The cover becomes the file thumbnail, so it should be readable at a small size. Some teams add a link to the brief or the repository, which is useful as long as somebody keeps it current.

All posts

Product design

Figma File Organization: Pages, Naming and Structure for Product Teams

Figma file organization for product teams: the page template, naming conventions and file structure we use so developers find the right frame first time.

By Mehdi HassanOct 29, 20267 min read

The short answer

Good Figma file organization means one file per product area, the same page template in every file, and names a developer can search. Put a cover and a read-me first, separate ready-for-dev work from explorations, keep shared components in a library file, and archive old ideas instead of deleting them, so nobody builds from a stale frame.

Key takeaways

Organize by product area, not by designer or by date. People look for features, not for authors.
Use one page template across every file so anyone can find ready-for-dev work in seconds.
Separate explorations from approved screens on different pages. Mixing them is how stale frames get built.
Name frames like routes and components like code: Settings / Billing, Button / Primary / Large.
Keep components and variables in a library file and consume them, rather than copying them between files.

Part of Design-to-Development Handoff: How to Ship Designs Without Losing Detail

What does good Figma file organization look like?

Good Figma file organization lets someone who has never opened the file find the approved version of a screen in under a minute. That's the whole test. A developer, a new designer or a founder should be able to open the file, read the cover, jump to the right page and trust that what they see is current.

Most messy files fail that test for the same reason: explorations, approved screens and abandoned ideas live on one long canvas. File structure is the first layer of a good design-to-development handoff, and it's the cheapest one to fix. You don't need a plugin or a new plan. You need a template and the discipline to use it.

How should a product team structure Figma projects and files?

Structure Figma as team, then project, then file, and split files by product area. A project maps to a product or a website. Inside it, each file covers one area people work on together: onboarding, billing, the dashboard, the marketing site. Files split this way stay fast, and their version history stays readable.

Level	What it holds	Example
Team	Everyone who designs or builds for one company	Acme
Project	One product or one website	Acme App, Acme Website
Library file	Components, variables, styles and icons	Acme / Design System
Working file	One product area, all its states	App / Billing and Plans
Sandbox file	Personal experiments nobody builds from	Sandbox / Mehdi

Avoid one file per designer and one file per sprint. Both feel tidy for a week, then force people to remember who worked on what and when. Organize around the thing being built, because that's what everyone searches for.

Which pages should every Figma file have?

Every Figma file should have the same page order, so the location of approved work never changes. We use a numbered template that also matches how we deliver a brand and design sprint: the words and brief first, explorations in the middle, and the chosen direction clearly separated from everything that didn't make it.

Page	What goes on it	Who reads it
00 Cover	File name, owner, status, last updated date	Everyone, as the thumbnail
01 Read me	What this file covers, links to the brief, library and repo	Anyone new
02 Brief and copy	The problem, the audience, the real words for each screen	Design and engineering
03 Explorations	Numbered directions, side by side	Design and stakeholders
04 Ready for dev	Approved screens and states only, in sections	Developers
05 Flows and prototype	Linked screens for review and testing	Stakeholders, testers
06 Local components	Pieces not yet promoted to the library	Design
99 Archive	Rejected or replaced work, labelled with a date	Nobody, unless asked

The numbers matter more than they look. They fix the sort order, they make pages easy to reference in a message ("see page 04"), and the 99 prefix keeps the archive out of the way without deleting the history behind a decision.

Hypothetical example: how a sprint file is laid out

For example, suppose a seed-stage SaaS team books a design sprint to refresh its brand and rethink the dashboard. Page 02 holds the positioning line, the dashboard copy and the brief in plain text. Page 03 holds ten numbered explorations, each in its own section titled with the idea it tests (Exploration 04: activity-first dashboard). After review, the chosen direction moves to page 04 with its states, and the other nine move to 99 Archive with the date and the reason they lost.

The team can reopen the file months later and still understand both what was chosen and why. That second part is usually what gets lost.

What Figma naming conventions should you use?

Use names that read like the product's own structure: frames named like routes, components named like code, and no default names left behind. A developer searching the layers panel for "Billing" should find the billing screens, not Frame 2318.

Frames: Area / Screen / State, for example Settings / Billing / Card declined. Match the route or screen name your developers already use.
Components: Category / Name / Variant, for example Button / Primary / Large. The slash creates folders in the assets panel, and the names can match your component files.
Component properties: use the same words as the code props (size, variant, disabled), so the mapping is obvious in Dev Mode.
Sections: name them for the flow they contain, such as Checkout: happy path.
Layers inside components: name the meaningful ones (Label, Icon, Helper text) and leave purely decorative ones grouped.

How do you show developers what's ready to build?

Show readiness with location and status, never with a message in chat. Only approved work goes on the ready-for-dev page, grouped in sections by flow, and each section is marked ready in Dev Mode when it's done. Developers can then filter for ready work instead of guessing.

If your team uses Figma Dev Mode, the ready-for-dev status and the notifications it sends replace a lot of back-and-forth. If you don't pay for Dev Mode seats, the page structure still does most of the work. Pair it with clear annotations for states and edge cases, and run the Figma handoff checklist before you change a section's status.

How do libraries fit into your Figma file structure?

Libraries hold everything shared, and working files consume it. Buttons, inputs, type styles, colors and icons live in one library file that every working file subscribes to. When a token changes, you publish once and every file gets the update, instead of hunting down copies.

Start the library small. A product team with one designer can keep components on page 06 of a single file until patterns repeat across areas, then promote them. When you do build it properly, our guides to component library design in Figma and setting up Figma variables cover the structure, and auto layout that maps to CSS keeps those components honest when they're built.

How do you set up a Figma file structure from scratch?

Set it up once as a template file, then duplicate it for every new area. It takes an afternoon and saves that time back on the first handoff.

Create the template file
Add the numbered pages, a cover frame with status fields and a read-me frame with link placeholders.
Connect the library
Enable your shared library in the template so new files start with the right components and variables.
Write the naming rules on the read-me page
Three or four lines with examples is enough. People follow examples, not policies.
Move existing work in
Sort current screens into ready for dev, explorations or archive. Anything nobody can vouch for goes to the archive.
Review the structure monthly
Spend fifteen minutes archiving finished explorations and promoting repeated local components to the library.

The structure only works if one person owns it. On our projects, the same team writes the copy, designs the screens and builds them, so the file is organized around what the developer needs next. If your file has outgrown your team's patience, a fixed-price brand and design sprint at $3,000 starts you with a clean, structured Figma file you can keep using.

Frequently asked questions

Should every feature get its own Figma file?: Not every feature. Give each product area its own file, such as billing, onboarding or the dashboard, and keep features inside it as sections. One file per feature creates dozens of tiny files with duplicated components and scattered history. Split a file only when it gets slow or when two groups work on it at the same time and keep stepping on each other.
Is it better to delete old designs or archive them?: Archive them on a dedicated page with the date and the reason they were rejected. Deleting removes the context behind decisions, and someone will eventually propose the same idea again. An archive page at the end of the file keeps that history available without cluttering the pages developers use. Version history helps too, but it is much harder to browse than a labelled archive page.
How do you name Figma pages so they sort correctly?: Prefix them with two-digit numbers, such as 00 Cover, 04 Ready for dev and 99 Archive. Figma shows pages in the order you arrange them, but numbers make that order explicit, survive reordering mistakes and make it easy to point someone to a page in a message. The 99 prefix is a simple way to signal that a page holds archived work.
Do small teams need a separate Figma library file?: A team with one designer can start with a local components page inside a single working file. Move to a separate library file once the same components appear in two or more files, or once a second designer joins. At that point, copying components between files creates drift, and a published library is the cheaper way to keep everyone on the same version.
What should go on a Figma cover page?: The file name, the product area it covers, the owner, a clear status such as in progress or ready for dev, and the date it was last updated. The cover becomes the file thumbnail, so it should be readable at a small size. Some teams add a link to the brief or the repository, which is useful as long as somebody keeps it current.

Mehdi Hassan · CEO & Design Director

Copywriter, designer and developer, and founder of Designify Studio. Over five years, 60+ projects across 14+ industries, for startups that have raised $300M+.

Want this done for you? Brand & design sprint, $3,000.

A brand refresh or redesign, plus design explorations for your website and product. $3,000, one-time, fixed price. Book a free 30-minute call to see if it fits.

Schedule Call