A Layer Naming Style Guide

Keep those design files tidy
January 2021

Last year, Sketch rolled out an intriguing new feature called Assistants. The tool allows designers to write short scripts that can check for inconsistencies or issues in a design file. As design teams continue to scale, the prospect of being able to enforce a universal style is extremely intriguing.

Software engineers have used similar tools for decades, often called linters. These tools run quietly in the background catching common errors & style inconsistencies. They help build consensus on teams around age-old debates of code formatting. Whatever the linter says goes.

Many other creative industries have these style guides for production-ready assets: writing, architecture, academia, etc. For whatever reason, a similar approach has never really caught on in digital product design.

Without a standard approach, I have developed my own internal rules for design files that have solidified over the years. Here they are:

1. Name layers

Most design tools apply a default name to any object you create: "rectangle 1", "frame 7", etc. Your first order of business after placing these on the page is renaming them to something that has meaning in the context of your design.

Two lists of layers from a design tool. The list on the left is poorly named using the defaults. The list on the right is properly named with meaningful titles.
Fig. Naming your layers makes it easy for others to understand your design files.

This is an essential habit to build at the start of a new project. No one wants to go back and retroactively name hundreds of layers hours later. It's also a show of respect to the other designers on your team. Folks will inevitably have to enter into your design files in the future and well-named layers make that process infinitely less painful.

2. Distinguish between static & dynamic text boxes

Layer names for static text on a page like headings and subtitles should be the same as the text itself for easy identification. If the text is particularly long, the first 3-5 words is sufficient.

Several examples of text naming conventions being used on a simple card design.
Fig. The tag text at the top is static. The titles & button text are dynamic.

Dynamic text used in repeating elements like buttons or form labels should be given a name that indicates what the text semantically represents. For example, the placeholder text in a form input might say "please enter your email", but the layer name should be "placeholder-text".

3. Name semantic objects consistently

Any objects in your layers that have semantic or structural meaning should be named in a consistent style. I tend to prefer lowercase with a dash between words: "notification-dot", "actions", "button-text", etc.

Several examples of semantic object naming conventions being used on a simple card design.
Fig. The image and chevron icon are semantic parts of the design.

These are the objects that make up the substance of a design: containers, text, actions, inputs, etc. You can think of them as somewhat analogous to HTML elements.

4. Name decorative objects & workarounds consistently

All design tools have their limitations, so it is inevitable that you'll need to include layers in your design for workarounds & decorative flourishes that aren't directly related to the structure of the design. For example: most design tools do not support individual borders on rectangles (yet!), so we usually need to introduce a line of some sort to simulate the effect.

An example of a decorative object naming convention being used on a simple card design.
Fig. The horizontal rule is simulating a CSS border as a small rectangle.

I usually prefix a "~" on layer names for these objects: "~indent", "~spacer-12", "~hr", etc. This helps visually distinguish them from the more substantive layers in my designs.

5. Name groups of objects meaningfully

We often group objects together in design tools to take advantage of additional layout features they provide (ex: Figma's auto-layout). These nested groups of objects can add up quickly, so it's important to give each set a meaningful name.

Several examples of group naming conventions being used on a simple card design.
Fig. The card text is an arbitrary group and the card content is a meaningful group.

For small and arbitrary groups of objects (2-3 in total), simply combine the names of the sub-layers together: "icon-title", "title-subtitle", "text-button", etc.

For large groups of objects or groups of objects that achieve some semantic meaning by being combined, name them accordingly: "sidebar", "content-header", "actions", etc.

6. Adopt the front-end's naming convention for components

For commonly repeated elements across your designs (usually a symbol or component in Sketch/Figma respectively), it's best to adopt the naming conventions used by your engineers in their front-end libraries.

Several examples of component naming conventions being used on a simple card design.
Fig. The button and the card itself are repeatable objects.

For example, in React it's common for components to be named using upper camel case: "Banner", "AlertNotification", "PrimaryButton", etc. Find out how your engineering team is naming theirs and use that approach for your own repeatable elements. Ideally it will also make sense to give the same names to components that are a one-to-one match between your designs and the codebase.

Wrapping up

Naming things is hard. Stopping to think about naming layers in the middle of an engaging design session can feel like the ultimate flow killer, but your future design self will thank you for it.

To not get bogged down in the moment means having a handle on a few key layer naming rules that you can always turn to. Hopefully one day tools like Assistants in Sketch will automate this work for us, but until than: keep those layer names tidy.

Credit to Alvy Martinez on Unsplash for the lovely photo of a floating house in Norway.