A Layer Naming Style Guide
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.
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.
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.
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.
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.
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.
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.