Framer
How I structure every Framer project before writing a single line
Clean component architecture is not just for developers. Here is the system I use on every build.

How I structure every Framer project before writing a single line
The first thing I do when I open a new Framer project is not build anything. I set up the structure. Variables, breakpoints, component hierarchy, naming conventions. All of it before a single frame is placed.
It takes about twenty minutes. It saves hours later.
Most people skip this step. They open Framer, drag in a frame, start building. It feels faster at the start. It is not. By the time the project is halfway done the layers panel looks like a yard sale and making any global change means hunting through forty frames manually.
Here is the system I use instead.
Step one: set up your variables first
Before anything else, define your tokens. Colors, typography, spacing. In Framer this means setting up your color variables and connecting them to your design.
I use a simple structure. Primary, secondary, background, surface, border, text, text-muted. That is usually enough for most projects. Complex projects might need more but starting with less and adding is always easier than starting with everything and cleaning it up.
Spacing works the same way. I define a scale at the start: 4, 8, 16, 24, 32, 48, 64, 96. Everything in the project uses one of these values. Nothing in between. When spacing is consistent, the site feels consistent. When it is arbitrary, something always feels slightly off even if the viewer cannot say why.
Step two: name everything properly from the start
This sounds tedious. It is. Do it anyway.
A layer called Frame 47 tells you nothing. A layer called Card / Featured / With Image tells you exactly what it is, where it fits and what variant it is.
The naming convention I use is: Component / Variant / State. So a navigation link in its active state becomes Nav / Link / Active. A card with no image becomes Card / Default / No Image.
When your layers are named this way three things happen. You can find anything instantly. You can hand the project to someone else and they can understand it without a briefing. And when Framer updates something about how components work, you know exactly what needs updating.
Step three: build the smallest repeating unit first
Every project has a smallest repeating unit. A button. A tag. A card header. An icon with a label.
Build that first. Get it right. Then build the things that contain it.
This sounds obvious but most people build top-down. They start with the hero section, then the features section, then somewhere in the third section they realise they need a button and they build it in place. Then they need the same button somewhere else and they build a slightly different version. By the end of the project there are six versions of the same button and changing the color means finding all six.
Bottom-up building means you build the atom, then the molecule, then the organism. Every layer is made of the one below it. Changes cascade correctly.
Step four: create a cover frame
Before I export or share anything, I create a cover frame at the top of the project. It shows the project name, the client, the version and the date last updated. It takes two minutes.
When you are working on multiple projects and come back to one after a week, that cover frame tells you immediately what you are looking at and where you left off. Small thing. Surprisingly useful.
Step five: document the decisions
Framer does not have a native annotation system the way Figma does but you can fake it with text layers set to a specific style. I use a small mono text style in a muted color for notes, placed outside the canvas bounds.
I document things like: why this breakpoint was set here, why this component deviates from the system, what the client requested that differs from the original design. Anything I would need to explain to someone else, or to myself in three weeks.
Why structure matters more in Framer than Figma
In Figma, a messy file is annoying. In Framer, a messy file breaks. Because Framer is also the production environment, disorganisation in the build directly affects the quality of the output.
A component built without proper variable connections will not update when you change the design token. A frame without correct overflow settings will clip content on mobile. A component with hardcoded values will not scale.
Structure in Framer is not just good practice. It is the difference between a site that is easy to maintain and one that is a nightmare to touch after launch.
Twenty minutes at the start of every project. It is worth it every time.
All projects I build follow this structure. When you get the handoff, the file is organised, named and documented so you can maintain it confidently.
