Naming things is widely acknowledged as one of the hardest challenges in software development and digital design. The language we choose shapes not only how we conceptualize abstract architectural ideas, but also the very conversations we have with our peers. This inherent difficulty often leads to widespread confusion surrounding colors, icons, user interface components, and core product features. Consequently, designers and developers alike frequently struggle to establish clear, scalable names for design tokens, HTML classes, and system variables.
Often, the labels we assign fall into one of two problematic extremes. They can be far too generic, making it nearly impossible to understand their precise intent or context, or they can be excessively specific, leaving little to no room for flexibility, scalability, and future reuse. Resolving this tension requires a closer look at established industry resources, proven naming conventions, and the practical systems developed by major design teams to bridge the gap between terminology and execution.
How To Name Things
When developers and designers look for inspiration when naming HTML classes, CSS properties, or JavaScript functions, traditional vocabulary can quickly run dry. To combat this, Paul Robert Lloyd created Classnames, a resource specifically designed to encourage creative thinking and push teams outside their traditional lexical comfort zones.
The platform provides carefully curated, thematically grouped lists of words that are ideal for code and design architecture. Users can discover terms that describe distinct types of behavior, structural likeness, hierarchical order, grouping mechanics, and associative relationships. Furthermore, the repository offers unexpected thematic collections inspired by nature, art, theater, music, architecture, fashion, and publishing—domains that do not instantly come to mind when writing stylesheet rules or component logic, yet offer vivid metaphors for complex systems.
How To Name Colors
Choosing the right name for a specific color value has historically been an arbitrary and subjective exercise. To bring standardization and creativity to this process, David Aerne maintains a massive repository of color names. Currently housing more than 30,000 unique color designations sourced from various historical references and thousands of individual user contributions, the project serves as an invaluable asset for digital creators.
Complete with an integrated color picker, a dedicated name search engine, and a variety of associated color-picking utilities, this repository provides a reliable reference point. By drawing from a shared, community-driven database, teams can avoid ambiguous hexadecimal references or overly literal color names, fostering better collaboration between design and code implementation.
How To Name Layers and Groups
In the realm of digital design files, maintaining order requires strict discipline, particularly when organizing layers, groups, and master components. Javier Cuello recently outlined a comprehensive set of naming best practices aimed at helping teams structure their files in a consistent and scalable manner.
According to Cuello’s guidelines, an effective name possesses a clear logical structure, remains concise, carries distinct meaning, is universally understood across disciplines, and avoids direct ties to temporary visual properties. By highlighting essential do’s and don’ts, these guidelines address the fine details that practitioners must navigate when designating sizes, colors, groups, layers, and reusable UI components.
How To Name Design Tokens
Building a flexible design token taxonomy that functions seamlessly across multiple products and brand variations presents a formidable architectural challenge. This exact obstacle was faced by the team at Intuit, the parent organization behind widely used platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. To solve this, the company engineered a flexible token system designed to transcend individual brand themes and act as a foundational infrastructure for a diverse ecosystem of digital products.
In a detailed case study, Nate Baldwin shared vital insights into the creation of Intuit’s design token taxonomy. The documentation outlines the pain points of their legacy systems, details the strict criteria established for the new architecture, and explains the implementation process. The initiative offers critical takeaways for organizations seeking to construct robust, scalable, and adaptable token taxonomies for their own enterprise design systems.
Frequent Names For UI Components
When teams struggle to name interface elements, examining how other organizations handle similar UI components provides an immediate shortcut to clarity. Rather than getting lost navigating dozens of individual design systems, Iain Bean compiled the Component Gallery, an exhaustive research project that centralizes real-world interface patterns.
The collection features comprehensive examples for more than 50 distinct UI components—ranging from basic accordions to accessibility-focused visually hidden elements—alongside alternative names commonly used across the industry. This repository functions as a powerful practical reference, easing the friction of component nomenclature and standardizing UI definitions.
How To Name New Features
Even the most thoughtfully engineered features frequently suffer from low adoption rates due to poor discoverability. True feature adoption is a deliberate process: users must first discover a feature, understand its value, try it out, learn its mechanics, and eventually integrate it into their existing daily workflows. Erin Gannon addressed this challenge directly in a practical guide focused on strategic feature naming.
According to these guidelines, successful names must be driven by authentic user needs and pain points rather than internal corporate jargon. Effective names signal the direct value or outcome of a feature—effectively communicating the "job to be done"—while tapping directly into the vocabulary of the target audience. By asking users to explain a feature in their own words, product teams can align their naming conventions with actual user mental models.
How To Name Variables (Taxonomy Map)
Managing a complex, multi-brand, and multi-themed design system requires advanced variable architecture. A prime example of this complexity in practice comes from the Vodafone UK Design System team, whose Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into an impeccably structured system of collections.
Building upon foundational work by Nathan Curtis, the Vodafone map illustrates the four core collections required to support a unified design infrastructure, mapping out clear connections from raw brand primitives to semantic tokens and page-level applications. This framework allows team members to instantly understand where a token is utilized and what it represents simply by reading its name. Additional approaches to token naming continue to emerge across the design community, supported by various Figma kits and educational resources.
Design Token Naming Guide + Inventory
To assist practitioners in mastering this specialized domain, Romina Kavcic developed an interactive tool dedicated to design token naming. The utility guides users through the core mechanics of token architecture, helping them configure customized naming structures encompassing components, categories, states, and roles.
Complementing this builder is a design token names inventory spreadsheet. Utilizing a streamlined four-level structure, the spreadsheet provides teams with a comprehensive bird’s-eye view of their entire token library, allowing them to easily append rows, themes, and modes without losing track of dependencies or sacrificing filtering capabilities.
Naming Products or Services
For teams tasked with naming an entirely new product or service, Onym serves as an open-source repository organizing essential tools, methodologies, and resources. The platform compiles brainstorming frameworks, vetting strategies, historical case studies, cautionary tales, industry agencies, and recommended reading lists to encourage new ways of thinking about naming strategy.
Wrapping Up
Ultimately, the correct name for any digital artifact is the one that is universally understood and actively utilized by both the product team and the end users. A significant amount of engineering and design time is routinely lost when cross-functional teams speak about the exact same system using disparate dialects—separating the specialized terminology of designers, developers, product managers, and customers. This linguistic fragmentation is a primary driver of workplace frustration and confusion.
When features or components suffer from low adoption, the root cause is frequently nothing more than ambiguous or counterintuitive naming. By actively identifying and cataloging naming conflicts for future resolution, teams can systematically reduce friction, clear up confusion, and collaborate more effectively across disciplines.
