Design tokens serve as the foundational elements of a design system, capturing design choices related to visual properties or styles that are then applied to components and patterns. The naming of design tokens plays a critical role in communicating design decisions, enabling a shared and cohesive language within a system. Design system expert Dan Mall once noted the importance of naming design tokens, emphasizing the significance of language in fostering consistency, communication, and productivity within a design system. As the cornerstone of human connection, language plays a pivotal role in shaping the quality of a design system and ensuring efficient work completion.

Establishing Structure for Your Design System

By adopting a tokenized approach, a structured and efficient method is implemented for managing and applying design properties. When developing a design system, it is essential to consider aspects such as consistency, flexibility, and scalability, which are closely linked to the design tokens used. The presence of well-defined building blocks simplifies the process of further development and streamlines creative workflows. A successful, scalable product requires meticulous organization and clear definition at every stage. Different naming conventions exist across systems; organizations develop their patterns based on their unique needs. For example, Google's Material 3 and Adobe's Spectrum each have distinct styles tailored to their specific requirements. These decisions are carefully considered, reflecting Conway's Law, which posits that organizations design systems that mirror their communication structures. It is essential to recognize the drawbacks of poorly named tokens in addition to knowing their benefits. Some disadvantages include:

Misinterpretation: Unclear or ambiguous token names can cause confusion among designers, developers, and other stakeholders, leading to misinterpretation and incorrect usage.

Increased learning curve: Poorly named tokens may require team members to spend more time and effort understanding their purpose and usage, thus increasing the learning curve.

Reduced reusability: Nonoptimal naming of tokens can limit their reusability as they may not effectively communicate their intended purpose or context.

Collaboration: Improper naming can hinder collaboration by creating communication barriers and misunderstandings between designers and developers.

As design systems utilize tokens as foundational elements, the structure and organization of tokens play a crucial role in defining their properties.

Analysing Different Levels

In general, it is advisable to utilize token names that are both modular and meaningful. Token names should be broken down into four main levels: namespace, object, base, and modifier.

Base: This is the core aspect of the token name and serves as the primary distinguishing feature. It sets the foundational style of the token, such as color, text, radius, etc. This style is typically applied to an object if named.

Namespace: This is the identifier for the token, representing the system, theme, or domain it belongs to.

Object: This level specifies the component group, component, or element within a component that the token is associated with. This could be a button, a form component group, or an icon element.

Modifier: This final element in the token name differentiates it from tokens with similar attributes in other sections. It represents variations like hover states, dark mode styles, or a 2x scale.

Varieties of Tokens and Process for Naming

A token name can consist of two parts at the same level. Utilizing these parts in different ways or omitting specific elements allows for the creation of various types of tokens - including global, alias, and component-specific tokens. It is recommended to name global tokens first with a corresponding value, and then progress from there. Taking a step-by-step approach simplifies the process and establishes a solid structure. Start by transitioning from abstract usage scenarios to more specific ones. While a hex-code may not convey usage information effectively, an alias or component-specific token name certainly would. For example, a token name should progress from the value (#F1F1F1) to a global name (gray-100), then to an alias token name (color-primary), and finally, if necessary, to a component-specific token name (button-primary-color-background-hover).

As the token inventory increases within a design system, the naming convention needs to be sustainable. Decision-makers must account for a range of possibilities. It is the responsibility of the design system's decision-makers to establish clear boundaries for expansion. This includes determining whether to focus solely on category/visual styles (such as color, font, and spacing), on specific components (like buttons, tabs, and cards), or on variations within these components (such as bold, semi-bold, hover state, and top margin).

Guidance and Recommendations

Avoid abbreviations: Rather than using abbreviations, opt for full words to maintain clarity and understanding among team members.

Be brief but descriptive: Use clear and concise language to effectively convey the meaning of each token.

Avoid duplicate or conflicting names: Ensure each token has a unique name to prevent confusion and conflicts during implementation.

Stay away from homonyms: Refrain from using words that have the same spelling or pronunciation but different meanings to prevent misunderstandings, especially in diverse team environments.

Conventions and Standards

Different organizations worldwide use various naming conventions for their tokens. These conventions include Pascal Case (PrimaryColor), Camel Case (primaryColor), Underscore Case (primary_color), and Kebab Case (primary-color). Each of these conventions has its own advantages and disadvantages. Ultimately, the organization must decide which convention best suits their needs in terms of readability, user experience, team comfort, consistency, and clarity.

Evaluation and Examination

It is important to note that token naming patterns may be effective for one system but not necessarily for another. Feedback and iteration play a crucial role in developing appropriate token naming patterns for your design system, ultimately leading to its success. Experimenting with different patterns and evaluating comprehension among team members is essential in determining the most suitable name. Here are some key components to consider when establishing your token naming pattern:

Clarity: It is important to make sure that token names clearly describe their purpose and how they are meant to be used. To test for clarity, ask team members to explain what they think the tokens do based solely on their names. This will help determine if the names are clear and easy to understand.

Consistency: Maintain a consistent ordering of levels in token names (e.g., object-action-property-state) and use consistent terminology throughout. Review a sample set of token names to identify any deviations and decide on the appropriate course of action to ensure consistency.

Scalability: Token names should be adaptable to accommodate new tokens without causing confusion or requiring major restructuring. To verify scalability, discuss hypothetical scenarios such as adding a new color scheme and assess if the existing token names can easily incorporate these changes.

Specificity vs. Abstraction: Consider the level of specificity needed in token names. Tokens should be specific enough to convey information about their usage or purpose, while also being versatile enough to be reused. Evaluate tokens in different contexts to determine if they are still effective and informative.

Incorporation: Conduct testing of tokens within technical environments to identify any potential issues, such as the utilization of reserved keywords in certain programming languages.

Conduct focus groups or surveys with your team to gather feedback on token names. Take note of any names that consistently lead to confusion or are frequently misinterpreted. Ensure that your token naming pattern is well-documented, including examples. Encourage team members to refer to the documentation when creating or using token names to assess the clarity and effectiveness of the guidelines.

Takeaway

Essentially, naming design tokens is an ongoing process that is crucial for building an effective and scalable design system that is user-friendly for the whole team. Keeping naming conventions flexible is essential as the system grows and changes. Following guidelines and seeking feedback helps refine token names and ensure they make sense to everyone involved. Efficient token naming is about creating a framework that promotes collaboration, consistency, and efficiency within the design system, rather than just labeling attributes. As the design system evolves, there is always more to learn and refine in the journey of naming design tokens.