Naming is widely recognized as one of the hardest problems in software development and digital design. The language teams use fundamentally shapes how they think about digital products, how they structure codebases, and how effectively cross-functional groups communicate. Across the tech and design industries, chronic confusion persists around colors, icons, user interface components, and features. This friction frequently trickles down into struggles when attempting to name design tokens, HTML classes, and variables in a scalable manner.
Often, the labels chosen during the design and development phases suffer from two extremes. Sometimes, they are far too generic, making it nearly impossible for team members to understand what a specific element is meant to represent or accomplish. In other instances, they are overly specific, locking the architecture into rigid constraints that leave little room for flexibility, scaling, or future reuse. Choosing the right names and establishing robust, predictable naming conventions remains a critical priority for modern engineering and product teams seeking to streamline their workflows.
How To Name Things
Finding the right inspiration for naming HTML classes, CSS properties, or JavaScript functions can often feel like searching in the dark. To combat this, developers and designers frequently look for external references that encourage thinking outside the box. One notable resource available to the community is Classnames, a curated platform packed with unconventional ideas and descriptive terms for codebases.
The site provides thematically grouped lists of words specifically organized for naming digital assets. Users can explore terms that describe different kinds of behavior, visual likeness, order, grouping, and association. Furthermore, it offers themed collections of words drawn from diverse domains such as nature, art, theater, music, architecture, fashion, and publishing—vocabulary that would not instantly come to mind during a standard coding or design session.
How To Name Colors
Establishing a clear and scalable system for naming colors is another major hurdle for digital teams. To address this, David Aerne maintains a massive repository of color names known simply as color-names, which currently houses over thirty thousand unique color designations sourced from various references and thousands of individual user contributions.
This repository is accompanied by interactive tools such as color pickers and name search utilities, as well as companion tools like Color Parrot, which allows users to assign or discover names for specific color inputs. This extensive collection serves as a vital reference library for designers and developers tasked with establishing cohesive color palettes across large-scale digital products.
How To Name Layers and Groups
Establishing consistency in vector files and component libraries is essential for collaborative design environments. Javier Cuello previously outlined a comprehensive set of naming best practices aimed at helping teams label their layers, groups, and components in a consistent and scalable fashion.
According to these guidelines, an effective name must possess a logical structure, remain concise yet meaningful, be universally understood across the organization, and avoid reliance on purely visual properties. By highlighting essential do’s and don’ts, these principles address the fine details required when managing sizes, colors, groups, layers, and nested components within collaborative design files.
How To Name Design Tokens
Building a flexible design token taxonomy that functions seamlessly across multiple products presents a significant architectural challenge, even for the industry’s largest tech organizations. This exact challenge was faced by the team at Intuit, the parent company behind widely used financial and productivity products such as Mailchimp, QuickBooks, TurboTax, and Mint. To solve it, the engineering and design teams developed a flexible token system designed to transcend individual brand themes and act as a foundational infrastructure across a diverse ecosystem of applications.
In a detailed case study, Nate Baldwin shared valuable insights into the creation of Intuit’s design token taxonomy, examining the friction points of their legacy systems and outlining the strategic criteria established for the new architecture. Similarly, Vodafone’s UK Design System team released a Variables Taxonomy Map via Figma, illustrating how complex multi-brand, multi-themed design systems can categorize tokens from primitive foundations to semantic application layers, drawing inspiration from foundational work by Nathan Curtis. Complementing these approaches, Romina Kavcic developed dedicated tools and inventory spreadsheets designed to give teams a clear, bird’s-eye view of their design tokens without losing track as systems scale.
Frequent Names For UI Components
When teams struggle to name interface elements, looking at established patterns across existing design systems is often the most effective starting point. To save practitioners from falling into exhaustive design system research loops, Iain Bean developed the Component Gallery, a comprehensive directory that aggregates interface components from numerous real-world design systems.
The collection features practical examples for more than fifty distinct UI components—ranging from basic accordions to complex visually hidden elements—while also documenting alternative names that these components commonly go by in different organizations. This resource is paired with visual dictionaries such as Name That UI, providing accessible references for standardizing component nomenclature.
How To Name New Features
New features frequently suffer from low user adoption, a problem often rooted in poor discoverability and confusing nomenclature. Feature adoption requires a deliberate progression: a capability must first be discovered, then understood, subsequently tried and learned, and finally integrated into the user’s existing workflow. Erin Gannon addressed this challenge in a practical guide focused on aligning feature names with user expectations.
Effective feature names are fundamentally driven by user needs and underlying problems. They should clearly signal the value or outcome of a feature—focusing on the job to be done—and leverage the actual language used by the target audience. By asking users to describe a feature in their own words, product teams can identify terminology that resonates naturally, thereby improving discoverability and comprehension.
Naming Products or Services
Beyond codebases and design tokens, naming an entire product or service requires a distinct methodology involving brainstorming, market vetting, and linguistic research. Resources like Onym serve as open-source repositories organizing tools, methodologies, and prompts to guide teams through the complex process of naming new ventures, helping organizations navigate everything from initial ideation sprints to cautionary branding tales.
Ultimately, the right name is defined by clarity and shared understanding between the development team, product managers, designers, and end users. Significant operational time is frequently wasted when multidisciplinary teams discuss identical concepts using entirely different internal dialects. By addressing potential naming conflicts and prioritizing intuitive terminology, organizations can systematically reduce friction, clear up confusion, and foster smoother collaboration across departments.
