How Figma files are named, structured, and connected to the rest of the team
Figma files are a form of communication. A well-organized file tells the next person where things are, what's approved, what's in progress, and how it all connects to the rest of the team. These standards define how files are named, structured, and versioned across three file types: the design system library, exploration files, and final designs.
The conventions here are defaults, not rules. They exist so that anyone on the team can find what they need without asking. Use them consistently and adjust them when something genuinely does not fit.
| File(s) | Purpose | Primary Owner |
|---|---|---|
| Design System Library | Central source of truth for components, tokens, and patterns. Shared across all other files. | Product Designer |
| Exploration Files | Sandbox space for in-progress work on new features or iterations. Anything goes here. | Product Designer, |
| UX Designer, | ||
| UI Production Designer | ||
| Final Designs | Reviewed, ready-for-handoff screens. Only what is approved lives here. | Product Designer |
The design system library is the source of truth for everything reusable: components, tokens, styles, and patterns. All other files pull from it. Changes here affect the entire product, so updates should be intentional and documented.
File: [ Link to Figma design system file ]
00. Overview
01. Tokens & Styles
02. Components
03. Patterns
04. Templates
Components are named using a three-part hierarchy. This keeps Figma's search results predictable and makes variant relationships clear at a glance.
Pattern
Category / Subcategory / State
Examples