Layer Names? Who Cares?

Why Semantic Naming is the Real MVP of Design

Should you name your layers? Why take the time? As long as design software has existed there has been a debate over whether or not designers should take the time to cleanly and articulately name each and every single layer in their files. Frame 239573 causes some similar anxiety to a phone full of red notification badges and simply cannot accept a design file with this faux pas as complete or professional.

While naming layers can be helpful for organization and navigation by others, there is something falling through the cracks when it comes to design developer handoff. Layers could be grouped according to design elements that are related to each other visually, but may not have any logical grouping or relation to their functional purpose. The question should not be, do I take the time to name layers or not to name layers? The debate should be about how we are naming our layers.

Enter semantic naming.

Semantic naming of layers and components is crucial for creating a consistent and scalable design system that everyone involved in the design and development process can easily understand and use.

Semantic naming involves giving meaningful and descriptive names to design elements, based on their function or purpose, in a way that is easy to understand and remember. This naming convention allows designers and developers to quickly identify and use design elements more efficiently and with fewer errors. Taking it a step further beyond layers what happens when we apply this same logic to something that is language agnostic such as design tokens?

A design token is an abstracted value or a named reference to a value that is used to define the visual design of a user interface. In other words, a design token is a single value that can be referenced and reused throughout a design system to ensure consistency in the visual design of a user interface. Design tokens can include values for properties such as color, typography, spacing, and other visual design elements. For example, a design token might define a specific shade of blue that is used throughout an interface, or a specific font size that is used for all body text. Token usage validates and enforces a dry/one-directional design to development workflow, where design changes are made in one place (the design tokens) and automatically propagated to the rest of the project.

How does this relate to semantic naming?

There are different levels of design tokens, including core, semantic, and component-level tokens.

Core Tokens
Core design tokens are the fundamental building blocks of a design system and define the basic design elements of an interface. They typically include values for properties such as colors, typography, spacing, and other visual design elements. Core design tokens are defined at a global level and are used consistently throughout the design system to ensure consistency and cohesiveness across the interface.

Semantic Tokens
Semantic design tokens, on the other hand, exist as an additional layer, more specific to the context in which they are used. By using semantic naming conventions, a more understandable and descriptive token is created that can be used across various components. Semantic naming helps to enforce a consistent and meaningful naming convention, making it easier to identify and use the design tokens.

For example, consider a core design token representing the primary color used in a design system. By using semantic naming, this token can be named something like label-primary instead of just primary, making it clear that this token represents a label color and is specifically related to the primary color of the system.

Component Tokens
Semantic naming conventions can be used to communicate the functionality of a component-level design token and make it easier for designers and developers to identify and use the appropriate tokens. By using descriptive and meaningful names, designers and developers can quickly understand the purpose of a design token and how it should be used. For example, a component-level design token for the background color of a card component could be named something like card-bg-color to indicate its purpose and use.

To me the consistent missing aspect of the layer naming debate is not about whether or not you name your layers, but what is the convention used and how does it help your design to development handoff process? Semantic naming and the naming convention chosen are far more important than just naming layers for organizational purposes. While naming layers can help to keep a design file organized, it is not enough to ensure a seamless one-directional design-to-development handoff process. The real value of semantic naming lies in its ability to communicate important information about design elements and design tokens consistently and meaningfully.