Designing smart means designing with order: when things are named the same for everyone, the team works smoothly and deliveries run without a hitch. In Figma, this translates into adopting a clear nomenclature for layers, components, styles, variables, and states, so that anyone can understand what each thing is at a glance. Establishing consistent naming rules increases speed, avoids confusion, and maintains visual consistency. in any project, from a simple UI kit to a mature design system.
Throughout this guide, you'll see how to build a complete taxonomy that covers everything from element types and their properties to naming grammar, structure, and ordering. You'll also learn how to leverage Figma AI to rename layers in bulk and implement variables as reusable tokens for advanced design and prototyping. The idea is that you end up with a common, working language that you can scale seamlessly..
The basics: why nomenclature matters in a design system
Before going into detail, it is worth establishing the framework: a design system in Figma brings together components, styles and rules that articulate the interface. Defining names consistently across the system is vital for maintaining consistency and efficiency.That way, your library doesn't become a jumbled mess of buttons that are almost identical but called by a thousand different names.
Within that system, properties and their values are key: color, typography, spacing, sizes, states, modes… The more consistent you are in naming each property and each value, the easier it will be to apply and maintain the overall appearance. in all parts of the product.
Practical organization of components and styles
When working with components, using descriptive and predictable names saves you time searching for and understanding instances. For buttons, for example, differentiate type and purpose (primary, secondary); and add the state (e.g., normal or hovering) where appropriate.
With icons, it's best to avoid generic ones like "Icon 123". Opt for recognizable names like "mail", "cart", or "networks" They should explain what they're about without opening the layer. That clarity is appreciated when filtering in the library and when inspecting from Dev Mode.
For interactive component states, name them so they are unambiguously distinguishable: for example, a main button at rest and its hover version should be clearly differentiated. Using a suffix or a state modifier does the trick (e.g., primary/primary-hover).
If you manage more than one design system in parallel, mark their hierarchy. Distinguishing between a "main" set and a "secondary" set prevents mixing pieces that don't belong together.especially in organizations with multiple brands or verticals.
Benefits of aligning names between design and development
Having the whole team use the same language reduces friction: when a developer reads the layer name and it matches the token or class in the code, implementation is more straightforward. Nomenclature is the glue that holds together collaboration between disciplines. and shortens review cycles.
Furthermore, when it comes time to audit or scale the system, identifying and grouping elements is straightforward if the naming rules have been applied consistently. Nominal consistency translates into maintainability and cost savings over time.
Steps to build your design system file in Figma
Building a solid system isn't a matter of time, but there's a clear path you can follow so you don't get lost along the way. Start with the essentials and document each decision to make it shareable.
- Inventory of key elements: define what you are going to standardize (palette, fonts, spacing scales, critical components such as buttons, inputs, cards…). Clear scope prevents rework later.
- File dedicated to the system: creates a specific file that acts as a source of truth. Separating the library from projects ensures that changes are better controlled and versioned..
- Componentize with criteria: structures the components and their variants following the chosen convention. The name should reflect type, purpose, and status when it touches.
- Define stylesText styles, colors, and effects with consistent names so they are easily found. It applies the same grammar and word-joining patterns..
- Document the use: add notes on when to use each piece, limits, and examples. A clear guide makes it easier for the entire organization to design "at the same temperature".
Taxonomy: components, objects, properties, and values
For a glossary to work, you first need to know what parts you are talking about and how they relate to each other. This taxonomy will serve as a map to ensure you don't leave any loose ends..
Components: base and compounds
In Figma terms, a component is a block with its own visual identity within the UI kit (like a card). A base component is a piece designed to nest inside others. (For example, the numeric button that only exists within a date picker). Some libraries label them as assets, snippets, parts, items, or subcomponents: the idea is the same.
Objects: containers and elements
An object is a piece within a component. There are two main groups: containers (boxes, sections) and elements (contents)Among the elements you will find text (label, title, subtitle, caption), other components (icons, illustrations, buttons, tables), vectors (circle, rectangle, polygon) and media (image, gif, video).
Properties and values
The properties are the variable parts (size, state, color, density, etc.). Each property offers a set of possible valuesFor example, the "state" property of a button can be normal, hover, pressed, disabled...
There are two families of values: variants and booleans. One variant supports more than two options (xs/s/m/l, or info/warn/error), while a boolean represents a typical yes/no (True/False, On/Off, ShowIcon/HideIcon).
Naming structure: modifiers and their position
Once you are clear about what you are naming (component, object, property or value), you must decide how to mark their differences. Modifiers help to distinguish variants, states, and contexts.
Types of modifiers
There are several ways to visually modify a name. You can use icons, symbols, or keywords. to reinforce your reading:
- Icon: for example, a symbol in front to indicate utility or status (only if your computer supports and understands it).
- Punctuation marks: prefixes or separators such as ._Base or sub-level markers.
- Words, acronyms and abbreviations: suffixes such as Item-List, Cell-Header, ShowIcon, BC_…
The important thing is that the convention is explicit and documented. If you combine modifier types, define priorities and use cases. to avoid chaotic mixing.
Modifier position
The order must be consistent throughout the entire system. You can place the modifier before (Item-List) or after (List-Item)The essential thing is not to alternate between both patterns without a clear strategy.
Grammar of nouns: type, number, initials and unions
Standardizing grammar makes names readable and predictable. Decide once and apply it alwaysOtherwise, exceptions that are hard to remember will grow.
Term type
Choose whether the name will be a verb, adjective, or noun, and in what form it is conjugated. Valid options: participle (Collapsed), present tense (Collapse), adjective (Collapsable), noun (Collapsible) or combinations like “is Collapsible”, “show Collapsible”, “icon before”.
Singular or plural
Define whether you name in singular or plural and maintain the pattern. Using Button/Buttons or Size/Sizes consistently makes searching and reading easierYou can also set a generic (“actions”) if it better groups multiple elements.
Initials and visual style
Set how you capitalize: Uppercase + Uppercase (Icon Before), lowercase + lowercase (icon before), Uppercase + lowercase (Icon before) or lowercase + Uppercase (icon Before). Capitalization is part of the system, not a minor detail.
Word pairings
How you combine terms defines readability and fit with the code. Common options: no space (iconBefore), with space (icon before), period (icon.Before), hyphen (icon-before), underscore (icon_before)Avoid combinations that impair reading if they do not add value.
Predefined styles (Case Styles) are under development that combine initials and unions: camelCase (no spaces and each word capitalized except the first), PascalCase (all capitalized and no spaces), kebab-case (hyphen and lowercase letters) and snake_case (underscore and lowercase letters)Choose the one that best suits your stack and be consistent.
How to sort: alphabetically, sequentially, and hierarchically
Beyond the name, the way long lists are ordered also matters for finding things quickly. Three approaches work well in libraries:
- Alphabetical: a–zoz–a (eg, bottom, left, right, top).
- Sequential: 0–10 or 10–0 (e.g., default/hover/active sizes or states).
- Hierarchical: from most to least or vice versa (e.g., primary, secondary, or info/warn/error severity levels).
Applying the same ordering criteria to all collections prevents each team from ordering "in their own way". Define your preference and document examples for ambiguous cases.
Implementation: audit and creation of the glossary
With the rules defined, it's time to put them into practice. You have two paths that you can even combine. to ensure landing:
Content audit
Review what has already been built: inventory components, objects, properties, and values with their current names. The goal is to reach a consensus on a single taxonomic system with design and development and plan the migration without breaking prototypes or handoffs.
Glossary creation
Whether you're starting from scratch or have already done the audit, define the structure, grammar, and order for each type of element (component, object, property, and value). The glossary becomes your “official dictionary” of names and in a resource for new members.
Figma AI for contextually renaming layers
Renaming hundreds of layers by hand is tedious. Here, Figma AI can save you time by using content, position, and layer relationships to suggest contextual names. The tool analyzes your selection and applies consistent names where it detects the default pattern..
There are deliberate limits: Figma AI only renames frames, groups, text layers, rectangles (and rounded ones) with image fill, and certain instances that still retain the default name of the main component (only the container, without touching sublayers). If a layer already has a name, is locked or hidden, or is an individual vector shape (ellipse, polygon, star, mesh) without an image, it will not be renamed..
You can start renaming in several ways: from the context menu with a right click, from Actions in the toolbar, or through quick actions by typing "Rename layers". If everything is already correctly named, you'll see the message "No need to rename layers," with the option to "Rename anyway" if you want to force it..
A useful detail: if you have identical unnamed layers in several top-level frames, Figma AI will rename the matching ones. This helps preserve smart animations and scroll positions in prototypes by maintaining nominal correspondence.
Variables in Figma: reusable tokens for design and prototyping
Variables store values that you can reuse in design properties and prototype actions, and they coexist with other design tools such as 3D design programs for Mac. They are the natural bridge for implementing design tokens and building interactive logic without duplicating frameworks.
Some practical uses: create and apply tokens (colors, fonts, spaces), switch between device sizes with immediate spacing adjustments according to your scale, preview texts in different languages with a change of context, or build a cart that calculates order totals. All this without multiplying unnecessary variations.
There are three main areas where they excel: design and design systems, advanced prototyping, and APIs. Mastering these three allows you to connect design, interaction, and automation. in a consistent flow.
Variables for design and systems
Use variables and modes to represent tokens and alternate contexts (light/dark, brands, regions). Color and number are the foundation for palettes, sizes, and densities.and you can map them to collections and modes to switch at a glance.
Typical resources in this area include introductory tutorials, guides to collections and modes, and comparisons between variables and styles to help you decide when to use each one. In summary: styles serve as visual presets; variables encapsulate parameterizable values with modes.
Variables for advanced prototyping
In prototypes, variables store states and properties that change through interaction. You can use actions to modify their values and thus alter appearance, content, or visibility without duplicating frames.
Combining variables with expressions and conditionals opens the door to dynamic strings, mathematical operations, and Boolean evaluations. With multiple actions and if/else logic, you stack complex behaviors in the same trigger..
Variable modes also play a role in prototypes: set values by context (e.g., theme) and use it in expressions to switch appearance in real time. The number of screens needed for rich scenarios is drastically reduced.
Variables and API (REST, plugins and widgets)
The variables are available in both the plugin API and the REST API. You can view, create, update, and delete variables, as well as link them to components from plugins.This enables tools such as importers/exporters or style-to-variable converters.
Widgets access variables through the plugins API (reading and creating), with the exception that they cannot directly link widget properties to variables. To synchronize with the repository, there are example GitHub actions that connect Figma variables to your codebase., in addition to community sandbox files for risk-free practice.
Good naming practices for layers and components
Set a prefix for the type (e.g., Btn, Card, Input) and a suffix for the state (hover, focus, disabled) or size (sm, md, lg). The recommended order is usually Type/Purpose/Size/Conditionand use uniform separators (kebab-case or PascalCase, whichever fits your stack).
Maintain consistency between layers and instances: the instance container must inherit the pattern of the master component. Avoid improvised local variations because they disrupt search and replacement.When it's time to change, do it in the master version and publish a new version.
For boolean properties, name the property, not the value: "Icon" with On/Off or True/False values; avoid "withIcon/withoutIcon" if your system uses boolean toggles. This aligns the language with the logic of the prototype and the code..
If your project includes more than one domain (e.g., backoffice and customer), add a scope to the collection or folder name. Separating by context reduces semantic collisions and promotes appropriate reuse.
Common mistakes and how to avoid them
One of the most common mistakes is not documenting the convention and letting each person name things "in their own way". Without guidance, the library becomes fragmented and the team's speed dropsProvide clear examples and borderline cases to eliminate doubts.
Another mistake: mixing joining and capitalization styles within the same component family (kebab in some, camel in others). This complicates filters, queries, and reading the layers panel.Define a default style and apply limited and justified exceptions.
Avoid meaningless names (“Frame 27 Copy 3”, “Rectangle 12”). If Figma AI can't help because names are already assigned, rename them manually or at the component level. and take the opportunity to consolidate the chosen convention.
Do not duplicate variants that are already resolved by a variable or a boolean in the component. The golden rule: fewer screens, more parameterizationYou'll end up with a lighter and more manageable library.
Adoption roadmap for teams
Start small with a set of high-impact components (buttons, inputs, typography, palette). Share the convention, gather feedback, and improve it before rolling it out to others.From there, migrate by modules and version.
If you're looking to accelerate your mastery of these practices, consider intensive, product-oriented training. Programs taught by active professionals help to put theory into practice in real-world cases. already integrating Figma with development processes.
The key to all of the above is to treat nomenclature as part of the design, not as an afterthought. With a clear glossary, grammar and structure rules, Figma AI support, and well-defined variables, your system gains speed, consistency, and scalability.And your team, quality time to focus on user problems and not on fighting over names.
