Naming Conventions

When designing in Quest, it’s good practice to start naming your layers, groups and frames. The names of these will export with the design itself and carry over into the code. To help the development process, it is important to make sure things are named properly and at the very least, you should try to name everything that will have dynamic content.

You want to be sure your components have the correct name so your development team knows what to do with it and find it later in both Quest and in the code, but each layer can be as important. For instance, when you add a Buy button that you got from the Design Kit, it will only be named “Button/Contained” in the layers. This can be confusing for the developer to know which button that is exactly when referencing it in code. A better name would be “Buy button, Card 1” so they can see the intent and location of the button in the product. This may not be obvious at first because it’s clear inside that component but once things start nesting and there’s multiple components and cards within a page, that name can make it 100% clearer for everyone involved in coding it.

Additionally to naming, each relevant layer a unique name is equally important. If you have several profile pictures in your design layout and you name them all “ProfilePic”, Quest will export those layers with the naming convention of “ProfilePic_1, ProfilePic_2, ProfilePic_3” etc. While this technically isn’t wrong, it again is confusing as to which is which with only a number associated with it. Are they named that in vertical or horizontal order? There can be a lot of questions from the developer. A better naming convention might be “ProfilePicMain”, “ProfilePicSmall” and “ProfilePicHidden”. Anything that helps describe the situation better to the developer who has to add the code logic will go a long way to building the product faster. Also, for the most part it is good practice to try to avoid using non-numbers and letters as they can potentially be a problem in the code.

Natively, when adding multiple properties to a component with variants, Figma will automatically add the values to the layer name. This is helpful to see the exact use of that button and what it does. When you copy and paste that button’s instance into your own custom component design however, it will only show it as “Button” as that is the name of the component itself. So it is good practice to rename that component to something similar to the variant’s name of the component so that it’s more clear to the developer which exact button it is. And even if not using components, that clear designation helps in all cases where your design will need to have additional code.

Also make sure image assets are named properly. For instance, you don’t want your logo to be exported as “image2” if it is your brand logo, it is better to call it something like “OurLogoVerticalMed” to give it some better description. Also, whenever you use that same logo image elsewhere, it is good to keep that same name so there will only be one image asset instead of having multiple images that are essentially the same but end up in a folder with different names.

id binding

If you're working with a Figma file that is a mess with naming conventions, you can always use the "id" binding to give it the value you want it to be. This is ideal if you don't have access to the Figma file or your designer is just not that organized ;)

Helpful Links

To make it easy to rename layers, you can use the Figma rename feature which lets you quickly rename multiple layers at once. Learn more about it in detail here:

https://help.figma.com/hc/en-us/articles/360039958934-Rename-Layers

And last but not least, these are just quick tips that may help your team but every team has their own way of doing things so none of these are mandatory. The more

For further reading, we recommend this article:

https://uxdesign.cc/how-to-help-bridge-the-gap-between-ux-design-and-code-1b4442604bd9