Every design team loses hours to files nobody but the author can navigate. “Rectangle 47” and “Group Copy 3” are silent tax on collaboration. This guide gives you a naming system for layers, components, and files that stays searchable as projects grow, plus the mistakes that quietly erode it. The payoff is simple: anyone on the team can open your file and find what they need in seconds.
Why naming is a real design problem
Naming is not tidiness for its own sake. Layer and component names are the interface between your file and everyone who touches it later: teammates, your future self, and increasingly the developers reading exported assets and design tokens. When names are meaningless, people rebuild instead of reuse, handoff slows, and design systems drift. The cause of most chaos is not laziness; it is the absence of an agreed pattern, so everyone invents their own.
A naming system that scales
Name by purpose, not by shape
“Ellipse 12” tells you nothing. “avatar-badge” tells you what it is for. Purpose-based names survive redesigns because the intent stays even when the shape changes. Reserve shape names for genuinely generic decoration.
Use a predictable structure
Adopt a consistent order so names sort and search well. A reliable pattern is type or role first, then variant, then state. For example:
- button-primary-default
- button-primary-hover
- button-primary-disabled
Because the shared prefix comes first, all button variants cluster together in any search or layer list.
Pick one casing and stick to it
Kebab-case (words joined by hyphens) reads cleanly and matches how many codebases name things, which eases handoff. The specific choice matters less than applying it everywhere without exception.
Mirror the component structure the developers will use
When your component names echo the front-end structure, handoff gets faster because the mental model matches. If engineering has a Card with a header, body, and footer, name your layers to match rather than inventing parallel vocabulary.
Files and pages, not just layers
The same discipline applies one level up. Name pages by function: “01 Cover,” “02 Components,” “03 Flows,” “Archive.” Number them so order is intentional. Keep a clearly labeled “Archive” or “Scratch” page so exploration does not pollute the canonical work. A stranger should understand your file’s structure from the page tabs alone.
A real scenario
A product team shared a Figma file where every button was a detached copy named “Group.” A new designer needed to update the primary button style and could not find the source, so they styled a new one by hand. Now two slightly different primaries existed, and the inconsistency shipped. After the team adopted a “role-variant-state” convention and a single named component set, the same update took one edit and propagated everywhere. The fix was not talent; it was a name people could search.
Common mistakes and how to fix them
Default auto-generated names left in place
Fix: rename as you create, not later. “Later” never comes. Build the habit of naming a layer the moment it earns a place in the file.
Over-naming every trivial layer
Fix: name what others will search for, components, key groups, and reused elements. A decorative divider inside a well-named group does not need its own descriptive name. Balance matters; naming everything is as noisy as naming nothing.
Inconsistent order and casing across the team
Fix: document the convention in one short page inside the shared file and link it in onboarding. A rule that lives only in one person’s head is not a convention.
Names that describe appearance instead of role
Fix: “blue-box” breaks the moment the brand color changes. “card-featured” survives. Always encode the job, not the current look.
Action checklist
- Name by role or purpose, never by shape or color.
- Use a fixed order: type, then variant, then state.
- Choose one casing (kebab-case works well) and enforce it.
- Rename layers as you create them, not in cleanup.
- Only name what teammates will search for.
- Number and label pages so file structure is obvious.
- Keep an explicit Archive or Scratch page.
- Write the convention down in the shared file.
Conclusion and next step
Searchable names turn a personal file into a team asset. The system is small: name by purpose, keep a consistent order and casing, and write the rule down. Your next step: open your current working file, rename the ten most-reused layers or components by role, and add a one-page convention note so the habit spreads.
FAQ
Does layer naming really matter if I work alone?
Yes. Your future self is a collaborator with no memory of today’s decisions. Naming also makes it far easier to reuse work across projects and to hand off if the project ever grows.
Should design layer names match code exactly?
They do not need to match character for character, but aligning the structure and vocabulary reduces translation errors at handoff. The closer the mental models, the smoother the collaboration.
How do I get a whole team to follow a convention?
Write it down in one short, visible page inside the shared file, keep the rules few, and include it in onboarding. Conventions spread through low friction and repetition, not long documents.
Is there a tool that auto-names layers?
Some plugins can rename or clean up layers in bulk, which helps with backlog. But tools cannot decide intent. The naming pattern still has to be a human decision the team agrees on.
References
Figma’s official documentation and community best-practice guides cover file, page, and component organization. Nielsen Norman Group has published guidance on design system maintenance and naming that many teams reference.