How I structure a Figma file so my future self doesn't hate me

Figma files tend to start organized and become a mess. The first few days are clean. Then deadline pressure hits, exploration frames multiply, components get built in place, and three months later nobody can find anything. The file is a liability.

This isn't laziness. It's the default behavior of a tool that makes it frictionless to create things and provides no structure for containing them. You have to build the structure yourself.

Here's the system I use.

The page structure

Every project file gets the same page structure, in this order:

Cover. A single frame with the project name, a thumbnail, status, and the last-updated date. This is what you see in the file browser and what collaborators see when they open the file. It takes ten minutes to set up and saves confusion forever.

Flows. The actual design work, organized by user flow rather than by feature or component. One section per distinct flow, named with a verb: "Onboarding," "Settings update," "Checkout." Flows contain the current, approved state of the design.

Exploration. Everything that's in progress, being tested, or hasn't been decided yet. Exploration frames are messier and that's fine. The key is that they're separate from Flows so reviewers know they're looking at something provisional.

Archive. Old versions, rejected directions, work that's been superseded. Moved here instead of deleted. Deleted frames are gone; archived frames are searchable if you need to revisit a decision six months later.

Component sandbox. Where I build and test new components before they graduate to the design system. This page is rough by design.

This structure means anyone opening the file knows immediately what's current, what's being explored, and what's been decided. It sounds obvious until you've worked in a file that doesn't have it.

Frame naming

Every frame I want to present or share gets a specific name. The format I use:

[Flow] / [Screen] / [State]

So: Checkout / Payment / Error, card declined or Onboarding / Welcome / Default.

The slash-separated format creates a visual hierarchy in the layers panel. The state suffix makes it possible to find the right frame when there are twelve versions of the same screen. Frames named "Design v3" or "NEW NEW FINAL" are useless to anyone who didn't create them.

Component frames inside the sandbox get [Component] / [Variant]. Every other frame that's not a real design artifact gets a descriptive name prefixed with _ to sort it to the top: _Notes, _Reference, _Annotations.

Section use

Sections are for grouping related frames within a page. I use them consistently:

In Flows, one section per user journey or feature area. The section name is the flow name. Frames inside are in left-to-right reading order following the user path.

In Exploration, one section per thing being explored. "Payment flow alternatives" contains all the competing directions for that specific decision. When a direction gets chosen, the winner moves to Flows and the rest move to Archive.

The key rule: sections within a page should represent meaningful groupings, not just visual spacing. If you have a section that contains one frame, you don't need the section.

Layer hygiene

I don't have strong opinions about layer naming during exploration. But any component or frame that leaves exploration and enters Flows gets named properly before it moves. This means:

• No "Frame 1" or "Rectangle 42" layer names
• No unnamed groups (converted to frames with names)
• Component layers named with the component's published name, not a description of what it looks like
• Text layers named by content or role, not "Text" or "Label"

This takes maybe five minutes on a moderately complex screen. It saves thirty minutes of confusion in the next review when someone is trying to understand the layer structure.

Variables and styles

All colors and typography in a project file reference styles or variables, never hardcoded values. This is non-negotiable. If you hardcode a color in one frame, you'll do it in another, and six months later you'll have two versions of the same gray and no way to update them together.

Variables live in a separate library file, not in the project file. The project file consumes them. This keeps variable definitions in one canonical place and makes updates propagate correctly.

The exception: exploration frames where I'm testing a new color direction. Those can have hardcoded values temporarily. They get cleaned up before moving to Flows.

The reset habit

The thing that actually maintains a file over time isn't any particular structure. It's a regular reset. Every two weeks or so, I do a fifteen-minute file maintenance pass:

• Move any finished Exploration frames to Flows or Archive
• Delete dead frames that will genuinely never be needed
• Rename anything that got lazily named during a crunch
• Update the Cover page status and date

This sounds like housekeeping and it is. But it's the difference between a file that stays usable for a year-long project and one that becomes an archaeological site after three months. The maintenance habit is as important as the structure.

---

None of this is about perfectionism. It's about respect for future-you and for the other people who will open this file. A well-organized Figma file communicates professionalism. A chaotic one communicates that the designer wasn't thinking about the process of making the work, only the work itself. Both of those impressions are accurate.