Naming things remains one of the most persistent and vexing challenges in software development, user experience design, and product architecture. The language professionals use not only shapes how they think about digital interfaces, but it also dictates the quality and clarity of the conversations they have about them. Across the digital industry, widespread confusion frequently arises around colors, icons, user interface components, and features. This linguistic friction directly translates into struggles when teams attempt to establish coherent naming conventions for design tokens, HTML classes, and code variables.
Often, the labels chosen during the design and development phases swing to extremes. Some names prove far too generic, rendering it nearly impossible for team members to understand the exact intent or context. Conversely, other names are far too specific, severely restricting flexibility, scalability, and reuse across larger systems. Addressing this structural dilemma requires examining how digital creators choose the right names, evaluating which naming conventions work best in practice, and exploring the emerging array of community-driven resources designed to solve these systemic communication breakdowns.

How To Name Things
Finding the right inspiration for naming HTML classes, CSS properties, or JavaScript functions often requires looking beyond standard technical dictionaries. For professionals seeking to break out of conventional naming habits, resources like Classnames, developed by Paul Robert Lloyd, provide a wealth of alternative ideas designed to stimulate lateral thinking.
The platform offers thematically grouped lists of words curated specifically for labeling code and structural elements. Users can explore terms that describe behavioral patterns, functional relationships, hierarchical order, and group associations. Furthermore, the platform includes unexpected themed collections drawn from disciplines such as nature, art, theater, music, architecture, fashion, and publishing. By tapping into these diverse vocabularies, developers and designers can craft more descriptive and evocative class names that avoid bland, repetitive technical jargon.

How To Name Colors
Establishing a standardized color palette introduces another layer of complexity, particularly when attempting to assign intuitive names to hundreds of distinct shades. To address this challenge, David Aerne maintains an extensive open repository of color names. This comprehensive database currently houses over 30,000 unique color designations, sourced from a variety of historical references and augmented by thousands of individual user contributions.
The repository is integrated with practical tools such as color pickers and name search utilities, including the color-matching project known as Color Parrot. These utilities allow creators to instantly retrieve descriptive names for specific hex codes or color values. Maintaining access to such comprehensive references helps design and engineering teams establish consistent color taxonomies without resorting to arbitrary numerical codes or overly subjective descriptions.

How To Name Layers and Groups
Within collaborative design environments like Figma or Sketch, the internal organization of artboards, layers, and groups frequently falls into disarray without strict governance. Javier Cuello has addressed this operational bottleneck by summarizing a comprehensive set of naming best practices aimed at bringing consistency and scalability to design files.
According to these guidelines, an effective layer or component name possesses a logical structure while remaining concise and meaningful. Crucially, successful names should be universally understood across multidisciplinary teams and should avoid direct ties to temporary visual properties. By establishing clear directives regarding what to do and what to avoid, teams can prevent design files from becoming cluttered, unsearchable archives, ensuring that both designers and engineers can navigate complex component libraries with ease.

How To Name Design Tokens
As organizations scale their digital products across multiple platforms and brands, establishing a flexible design token taxonomy becomes an urgent priority. This exact challenge was faced by the design systems team at Intuit, the parent organization behind widely used financial and productivity products such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify these diverse offerings, the team developed a flexible token system designed to function far beyond the constraints of any single brand theme, establishing a foundational architecture for a wide array of products.
Nate Baldwin documented the creation of this taxonomy in a detailed case study, outlining the specific pain points of their legacy systems, the strategic criteria established for the new architecture, and the implementation process. The insights shared from Intuit’s initiative offer valuable takeaways for organizations looking to build robust, scalable token taxonomies that can withstand the demands of enterprise-level product ecosystems.

Frequent Names For UI Components
When teams struggle to name custom user interface elements, examining established design systems offers a reliable starting point. To streamline this research process, Iain Bean compiled the Component Gallery, an exhaustive collection that aggregates interface components sourced directly from real-world design systems.
The gallery catalogs examples and alternative terminology for more than 50 distinct user interface components, ranging from common elements like accordions to specialized patterns such as visually hidden utility classes. By analyzing how different organizations label identical UI patterns, teams can align their internal naming conventions with broader industry standards, reducing cognitive load for incoming developers and designers. Additionally, supplementary resources like Name That UI serve as visual dictionaries to help bridge the terminology gap between disciplines.

How To Name New Features
Beyond foundational code and UI components, the nomenclature applied to user-facing features plays a direct role in overall product adoption. Features frequently suffer from low engagement not due to inherent flaws, but because of poor discoverability and unclear titling. Feature adoption requires a deliberate progression: users must first discover a feature, understand its purpose, try it out, learn its mechanics, and eventually integrate it into their established daily workflows.
UX writer Erin Gannon addressed this challenge through a practical framework focused on feature nomenclature. Effective feature names must be rooted directly in user needs and specific problem domains. Rather than relying on internal engineering codenames or corporate marketing jargon, successful feature names signal the tangible value or outcome of the capability—focusing on the job to be done. By interviewing users and incorporating the exact phrasing they use to describe their tasks, product teams can craft intuitive names that resonate immediately with their audience.

How To Name Variables and Taxonomy Maps
Managing variables in complex, multi-brand environments requires rigorous structural organization. A notable implementation of this approach comes from the Vodafone UK Design System team, whose published Variables Taxonomy Map illustrates the intricate anatomy and categorization required for a modern design token system.
The mapping framework breaks down the hierarchy of tokens across four essential collections, tracing connections seamlessly from foundational brand primitives up to semantic definitions and page-level applications. Building upon established methodologies such as Nathan Curtis’s work on design token architecture, this taxonomy structure enables team members to immediately deduce where a token is deployed and what it represents simply by reading its identifier.

Complementary tools developed by practitioners like Romina Kavcic, including interactive token naming guides and structured token inventories, provide teams with birds-eye views of their design variables. These inventory spreadsheets allow organizations to introduce new themes, modes, and categories without losing track of their token dependencies.
Naming Products or Services
At the highest level of product development, selecting a name for a new venture, product, or service involves navigating trademark constraints, linguistic connotations, and market positioning. Open-source repositories like Onym aggregate methodologies, brainstorming techniques, vetting guides, sprint frameworks, and etymological resources to assist teams through the naming lifecycle. By centralizing these resources alongside industry literature and agency references, creators gain structured pathways to explore alternative directions when establishing new brand identities.

Ultimately, the most effective name is the one that is universally understood and consistently utilized by both the internal product team and the end users. A significant amount of operational time is routinely lost when designers, developers, product managers, and users speak about the exact same system elements using entirely different internal dialects. Recognizing that low feature adoption or team friction can stem purely from misaligned nomenclature allows organizations to address naming conflicts systematically, reducing confusion and fostering more cohesive collaboration across disciplines.

