Figma | Nested Folders Bring Order to Design Libraries
Nested folders may look like a small organizational feature, but adding another level to an established design platform affects navigation, naming, data structures, collaboration, and plugin behavior. Figma's account of building the feature shows how careful product and engineering decisions can make large collections of reusable styles easier to navigate without disrupting the workflows that teams already depend on.
Nested folders turn long style lists into usable hierarchies
A design library can begin with a manageable collection of colors, text styles, effects, and layout grids, then become difficult to scan as the system grows. A single flat folder level leaves teams choosing between long lists, abbreviated names, or naming conventions that contain more information than the interface can comfortably display.
Nested folders introduce a clearer hierarchy. Related assets can remain under a broad category and then be divided into more specific groups, helping designers locate the correct style without removing the naming structure that gives the library its meaning.
A simple interface depends on a precise folder model
Figma represents a folder hierarchy through delimited style names. A style named with a path such as `brand/background/primary` belongs to the `primary` entry inside `background`, which itself sits inside `brand`. The visible folders are therefore connected to the style's complete name rather than stored as unrelated decorative containers.
This approach preserves compatibility with existing naming workflows, but it also creates technical details that the interface must handle consistently. Empty folder names are not valid, spaces around path segments need predictable treatment, and two folders may share the same visible name when they belong to different parents.
The complete path keeps repeated folder names unambiguous
A folder called `primary` could appear inside separate color, typography, or brand branches. Using only that final word would not identify which folder a command is meant to change, so Figma refers to nested folders through their complete delimited path.
This matters when styles are renamed, moved, or managed programmatically. The hierarchy must continue pointing to the intended branch even when another part of the library contains a folder with the same local name. For teams, clear parent categories also make those repeated terms easier to understand when browsing the library.
Folder reordering also needs to respect the hierarchy
Figma's plugin API includes separate methods for reordering folders that contain text, paint, effect, and grid styles. A folder can be moved relative to another folder only when both share the same parent, preventing a simple reorder action from silently changing the structure of the library.
For plugin developers, this means folder management cannot be treated as a flat list operation. Integrations that inspect, rename, or reorganize styles need to work with complete paths, preserve parent-child relationships, and account for the type of style contained in each branch.
Naming conventions affect exports as well as libraries
The slash character already carries structural meaning in Figma. When layers prepared for export use slash-separated names, exported assets are placed into matching nested folders. A layer named `icons/navigation/arrow` can therefore become an `arrow` file inside the corresponding directory structure.
This can be useful when a design system's asset hierarchy should continue outside Figma, but it also makes naming decisions operational. Teams should agree on when a slash represents a deliberate folder boundary so library organization and exported files do not acquire unexpected structures.
REMEMBER: Review existing slash-separated style and layer names before changing a naming convention. Slashes can define folder hierarchies for reusable styles and exported assets.{alertSuccess}
Daisuki's Take: What This Means for Designers
Nested folders are most valuable when they reflect how a team thinks about its design system. A hierarchy built around purpose, platform, theme, or component family can shorten the search for an asset, while unnecessary depth can simply replace one long list with several confusing branches.
The feature also shows why organization is part of design infrastructure rather than visual housekeeping. Folder names affect discoverability, plugin behavior, maintenance, and the way assets leave the design file, so their structure deserves the same consistency as component and variable naming.
We would introduce additional levels only where users repeatedly struggle to distinguish related styles. Before reorganizing a shared library, teams should test the proposed paths with real searches and export tasks, then document the convention so designers and developers interpret the hierarchy in the same way.
Sources and Recommended Links
- Code, Craft, and the Making of Nested Folders | Figma Official Blog
- BaseStyle: Folders | Figma Developer Documentation
- Export Static Designs from Figma | Figma Official Help Center
