Table of Contents
If I come across another file like this, I might lose it.
Good design hygiene is often overlooked, but it highlights your attention to detail. It’s one of the qualities that defines a great UX designer, shows that you care and are a professional in your field.
Some may think it takes time and does not add value to your workflow. Does it really matter?
A simple project can become messy over time, especially if multiple people contribute and team members change. While it may be tempting to skip naming conventions for quick, small projects, it’s important to establish them for larger projects that involve multiple designers or require ongoing maintenance.
Even for smaller projects, adopting naming conventions can help reinforce design best practices.
Disclaimer: There is no right or wrong way to name things in Figma. The naming convention depends on who you work with and your team’s naming guide. What’s right is what works best.
How you should name your design also depends on which stage of designing you are in. In the beginning state, where you just play around with ideas, you don’t even have to name anything.
The bigger and the more mature your system is, the more you have to take notice of the naming. There are 1000 ways to name things, but we can definitely start somewhere, this is it.
Who will use your design?
The most suitable naming convention depends on who will use your design. In my experience, developers do not care much about how you name things. They only see and copy the parameters, not the components’ names. So naming layers according to BEM (a CSS naming convention) is not making any sense.

I’ve noticed many users name components in Figma using formats like “.something__like–this” or “$just-like-this.” These styles are not practical for Figma’s current system. If needed, it’s best to mention this in the component description.
Most of the time, its users will be you and others who will maintain it, like other designers in a team.
You have to name it in a way that helps you find and maintain it later.
Many people forget that Figma is primarily a design tool, meant for designers who use it most often. It’s not a coding tool. Tools like Storybook and the “Design API” are there to help convert what Figma creates into code with proper naming conventions.
My approach
If your team does not have a naming convention, you can start with this. Without any standard, these are my internal rules for the design file.
Each frame on a page is named based on its most general purpose. For example, all buttons are labeled simply as “Button,” Text elements are named according to their function, such as “Title” or “Description.”
When elements have varying properties influenced by their parent elements, I ensure that my naming is more specific. For instance, a title may be labeled as “Card Title,” “Section Title,” or “Accordion Title,” depending on its context.
The key is to be as descriptive as possible also try to be simple and consistent.
For outer frames that primarily function for layout, I use simple labels such as “Container,” “Row,” “Column,” “List,” or a plural noun. When a frame is designed to resemble a card, I just label it as “Card.”
If the container comprises only two types of elements, I try to be more descriptive by naming them as element 1 + element 2. In this case, because the autolayout contains only icons and text, I name them ‘Icons + Input Text.’
I take a similar approach with components. Since we all use variants, most components should just have simple names, like “Button” for buttons.
This makes it easy for your team to find what they need and helps our engineers understand the designs quickly.
Camel case, title case or sentence case
From my experience with design systems, usability is the most important aspect, especially when creating something in Figma. Camel case just isn’t as easy to read as title case.
Camel case is helpful for naming variables and functions in coding as they don’t allow space or tabs in identifiers. If the people who work with layers most of the time are the designers, why do you want to name it for the developers?
When it comes to using title case or sentence case, there aren’t any studies that clearly show which one is better for readability. Personally, I prefer title case because it looks more professional, has a nice visual flow, and stands out better. It makes sense to use title case for short, descriptive titles.
On the other hand, sentence case feels more casual and works well for longer text. You can go with either style, but just make sure to stay consistent!
See more about the comparison between title case and sentence case in this article
Talk to your developers!
There’s a common belief that designers can create a perfect handoff for developers by organizing everything in Figma and naming layers well. But that’s not really how it works.
Every developer has their own way of interpreting designs, and each project is different. To really get it right, you need to talk with your developers. Ask them how they like things organized and named. Find out if your efforts are helpful and whether your naming aligns with front-end standards. Learn how they turn Figma designs into code and what kind of documentation they need.
Basically, at the start of every project, the best practice is to talk to your developers before doing anything else. This is all about having a conversation. It’s important to understand what developers want and adjust your approach accordingly.
If you’re practicing for a handoff without working with developers, you might be setting yourself up for failure. Naming conventions and processes need input from the development team.
If you deliver a well-organized design, like UntitledUI, without talking to your developers first, you could be wasting your time. The best way to learn how to work with developers is to collaborate with them, not just focus on naming layers.
You’re doing the right things, but you need to change the order. Start with conversations before getting into the details.
The best way to create a smooth developer handoff is to step away from the internet and talk to your team directly.
Conclusion
There are no strict rules for naming layers in Figma. It’s important to talk with your team to understand their preferred naming practices. Your naming approach can vary based on the project’s size and stage. If you’re just experimenting or working on a small, personal project that won’t scale, you might skip detailed naming.
However, in my experience, getting it right from the start can save you trouble later. If your team doesn’t have any naming practices, you can begin with the suggestions in this article and tweak them to fit your needs.