Designers have always had a practical reason to keep Figma files organised: somebody else eventually has to work with them. Another designer inherits the file. A developer builds from it. A new joiner opens it six months later and tries to understand what happened, what is current, and what can be ignored.
That reason has not gone away. A second audience has arrived alongside it. AI coding tools can now inspect design files directly, and they use the structure they find to decide what to build.
In 2026, I created a standardised Figma starter file for BMW Group’s design community. Around 200 designers picked it up without a mandate, which mattered because the file was not a policy document asking people to behave differently. It was a working default they could duplicate at the moment a project began.
This post covers why file structure matters more now, how to set up a useful starter file for an organisation, what to encourage, what to avoid, and what to check after rollout.
The starter file made the expected structure visible inside the file itself: pages for context, guidance, AI readiness, components, work in progress, handoff, and archive.
FIG. 1 - RECONSTRUCTED STARTER-FILE STRUCTURE
Why this matters now
AI tools can read your Figma file. Figma’s MCP server lets an AI coding assistant ask a design file what is inside a frame: which components were used, how things are spaced, what the layers are called, and how the screen is composed.
The design file has stopped being only a picture a developer looks at. It is also data that a tool reads.
A messy file used to cost a conversation. Now it can cost an implementation. When a developer could not tell which of three frames was the final one, they messaged the designer. That cost time and mild irritation.
An AI tool does not pause to ask the same question. It may pick one frame and build from it. If the button in that frame was drawn as a rectangle with a text layer on top instead of an instance of the real button component, the tool has no way to know that a governed component exists. The output can look close enough at a glance while drifting away from the design system and the codebase.
The same habits help both audiences. Clear frame names, real component instances, one obvious current version, and notes attached to the thing they describe were already useful for the next person. They now also make the file easier for a tool to interpret.
The point is not to organise files for machines instead of people. It is to recognise that machine readability now depends on the same structural care that made handoff better in the first place.
How to create a structured Figma file for your organisation
Start with a file people duplicate, not a document people read. A conventions page usually gets read once, often before someone has a real project to apply it to. A starter file gets opened when work begins. Put the standard in the thing people actually touch.
Put the guidance inside the file. I embedded short instructions directly in the starter file: what each page is for, how to name things, and where handoff notes belong. The designer should not have to leave the canvas to find out how to use the canvas.
Keep the page structure short. A practical default might include project context, exploration, work in progress, ready for handoff, and archive. The exact labels can change. The important part is that finished work and thinking-in-progress are visibly separate.
Name frames for the job they do. A name such as `Checkout / Payment failed / Mobile` gives a person and a tool the flow, the state, and the breakpoint before either one opens the frame.
Connect the starter file to the design system library. The file should already have the right components, colour styles, and tokens available. At BMW I linked the starter file to Density, the design system, so people started inside the system instead of recreating common parts by hand.
Give handoff notes a fixed home. Notes are only useful if someone can find them twice. Put them beside each flow, in a dedicated frame, or in another consistent place that suits the team’s way of working.
Keep the template small enough to survive contact with real work. If the starter file has twenty pages and a ceremony to follow, designers will delete most of it. A small, sensible default is easier to adopt and easier to improve from observation.
Dos and don’ts
Use these as checks when you review a file before handoff or before testing an AI-assisted workflow.
A designer-facing checklist turns file structure into a pre-handoff routine: clear pages, understandable layers, applied tokens, covered states, export-ready assets, linked resources, and AI-to-code readiness.
FIG. 2 - DESIGNER HANDOFF CHECKLIST
Do: name frames for what they are. `Search results / Empty state / Desktop` carries more useful information than `Frame 1289`.
Do: use real component instances. An instance of a design-system button carries a link back to a governed component with known variants and behaviour. A rectangle with text on it carries almost none of that context.
Do: keep one obvious current version. If three frames are all some version of "final", nobody and nothing can tell which one is true.
Do: separate exploration from handoff. A tool reading the file cannot infer that one page contains abandoned ideas unless the file says so structurally.
Do: use design tokens and shared styles. A token name gives a tool something meaningful to resolve. A raw hex value usually does not.
Don’t: detach components silently. Sometimes breaking away from the system is the right decision. When that happens, leave a note so a person or a tool can tell the difference between a deliberate exception and a mistake.
Don’t: turn the file into the requirements document. Put enough context in the file to interpret the design: the flow, the state, the open questions, and the handoff notes. Keep the full product requirements where the organisation maintains them, or the two sources will drift.
Don’t: hide important context in hidden layers. Hidden material is easy for a colleague to miss and ambiguous for a tool to interpret.
Don’t: mistake tidy for structured. A canvas can look polished and still be built from detached components, generic layers, and unclear states. Visual neatness and structural clarity are related, but they are not the same thing.
Don’t: expect structure to remove review. A well-organised file gives an AI-assisted workflow better input. It does not guarantee that the output is correct, and it does not remove the need for a person to review the implementation.
Follow-up items
Rolling out a starter file is the beginning, not the finish. The useful work starts when people begin using it on real projects.
Test it with a real AI workflow. Give an AI coding assistant a small, bounded task against a structured file: find the approved screen, identify the components used, and implement one part of the interface. Where it fails usually points to the convention that needs work.
Ask someone unfamiliar to find something. Give a developer who has never opened the file thirty seconds to find the current version of a flow. If they cannot find it, a tool is unlikely to handle the ambiguity well either.
The developer-facing checklist makes the receiving side explicit too: use Dev Mode, navigate the file deliberately, inspect spacing and properties, check component links, track changes, and clarify instead of assuming.
FIG. 3 - DEVELOPER DEV MODE CHECKLIST
Watch what people delete. The parts of the template that disappear first are usually the parts that did not earn their place. Remove or simplify them in the next version.
Give it an owner and a version number. Design systems change, tools change, and Figma ships new capabilities. A starter file with no owner slowly becomes wrong, and a wrong default is worse than no default.
Check it again when the tooling changes. What counts as machine-readable will keep shifting. Treat the file structure as a maintained product, not a one-time cleanup.
Where this leaves us
None of this asks designers to learn a new discipline. It is the same file hygiene teams have always needed, with a more immediate consequence attached to skipping it.
The upside is that the effort now pays in more than one place. A structured file helps the next designer move faster, gives developers a clearer handoff, and gives AI-assisted workflows something more reliable to read.
More detail on the starter file itself — what was in it, how it was rolled out, and what I would measure next time — is in the Figma starter-file case study.