Naming is widely acknowledged as one of the most persistent hurdles in digital design and software development. The language professionals use not only shapes how they conceptualize interfaces, but it also dictates the clarity of communication across multidisciplinary teams. This fundamental challenge often breeds widespread confusion regarding colors, icons, user interface components, and application features. Consequently, design professionals and developers frequently struggle when attempting to establish coherent names for design tokens, HTML classes, and code variables.
The struggle typically stems from two extremes. Often, the chosen names are overly generic, making it exceedingly difficult to discern their exact purpose or context within a system. Conversely, names can sometimes be too specific, severely restricting flexibility, scalability, and future reuse. Addressing this persistent industry pain point requires a closer examination of current methodologies, established naming conventions, and the growing ecosystem of resources designed to bring order to interface architecture.
How To Name Things
Finding inspiration for HTML classes, CSS properties, or JavaScript functions often requires looking beyond conventional technical dictionaries. Resources like Classnames, developed by Paul Robert Lloyd, offer a curated approach to expanding vocabulary and encouraging lateral thinking among developers and designers.
The platform provides thematically grouped lists of words tailored for code architecture. Users can explore terms describing behavior, likeness, order, grouping, and association, alongside themed collections drawn from unexpected domains such as nature, art, theater, music, architecture, fashion, and publishing. By stepping outside standard technical jargon, teams can discover descriptive identifiers that better capture the functional nuance of their code.
How To Name Colors
Establishing a standardized and intuitive nomenclature for color palettes presents another significant hurdle for digital creators. To combat ambiguity, David Aerne maintains an expansive repository of color names known as color-names, which currently catalogs over 30,000 unique entries sourced from various design references and thousands of user contributions.
Accompanied by interactive tools such as color pickers and name search utilities, including Color Parrot, this repository serves as a valuable reference for teams striving to maintain consistency across extensive multi-brand environments. Having a shared, human-readable vocabulary for color tokens bridges the gap between design specifications and frontend implementation.
How To Name Layers and Groups
Within design files, the organization and hierarchy of layers and groups directly impact handoff efficiency and design system maintenance. Javier Cuello has outlined a comprehensive set of best practices designed to help teams name layers, groups, and components in a consistent and scalable manner.
According to these guidelines, an effective name possesses a logical structure, remains concise yet meaningful, is universally understood across the organization, and avoids reliance on superficial visual properties. By adhering to established do’s and don’ts, teams can eliminate the clutter of default file names—such as "Rectangle 4 copy"—and replace them with semantic identifiers that reflect the underlying architecture of the interface.
How To Name Design Tokens
Building a flexible design token taxonomy that operates seamlessly across a diverse ecosystem of products represents a major architectural undertaking. This challenge was successfully tackled by the team at Intuit, the parent company behind major financial and productivity platforms including Mailchimp, QuickBooks, TurboTax, and Mint. The organization developed a robust token system designed to transcend individual brand themes and serve as a foundational infrastructure for a wide array of digital products.
In a detailed case study, Nate Baldwin shared insights into the creation of Intuit’s design token taxonomy, addressing the pain points of legacy systems and outlining the strategic criteria established for the new architecture. Similarly, the Vodafone UK Design System team released a comprehensive Variables Taxonomy Map via the Figma community, illustrating the complex anatomy and categorization required to support a multi-brand, multi-themed ecosystem. Built upon foundational work by figures like Nathan Curtis, these token maps connect brand primitives directly to semantics and page-level implementation, enabling teams to trace the origin and application of any token directly from its identifier.
Additional practical tools, such as Romina Kavcic’s Design Token Naming Guide and associated spreadsheet inventories, offer structured methodologies for configuring naming hierarchies that incorporate components, categories, states, and roles without losing track of dependencies.
Frequent Names For UI Components
When teams encounter roadblocks while defining interface elements, examining established design systems provides an immediate benchmark. To simplify this research phase, Iain Bean created the Component Gallery, a comprehensive repository cataloging interface components sourced from real-world design systems.
Encompassing over 50 distinct UI components—ranging from basic accordions to complex accessibility wrappers—the gallery documents the varied nomenclature used across the industry for identical interface patterns. This resource is complemented by visual dictionaries like Name That UI, which help bridge vocabulary gaps between different stakeholders.
How To Name New Features
Beyond technical code and design tokens, the naming of product features plays a critical role in user acquisition and long-term engagement. Low feature adoption rates are frequently linked to poor discoverability and confusing terminology rather than a lack of utility. Successful feature adoption requires users to discover, understand, try, learn, and ultimately integrate new capabilities into their existing workflows.
In her practical guide on feature naming, Erin Gannon emphasizes that effective names must be rooted in user needs and real-world problems. Rather than relying on internal corporate jargon or overly clever branding, feature names should signal the core value or outcome—the job-to-be-done—by tapping directly into the language used by the audience. Engaging users to describe functionality in their own terms provides invaluable linguistic data for product teams.
Naming Products or Services
At the highest level of abstraction, naming a product, service, or brand requires specialized methodologies encompassing brainstorming, vetting, etymological research, and strategic sprints. Open-source initiatives like Onym serve as centralized repositories organizing tools, guides, and professional resources to assist teams through the complex lifecycle of product naming while avoiding common pitfalls.
Wrapping Up
Ultimately, the most effective name is one that is universally understood and actively utilized by both the product team and the end users. Significant operational time is frequently lost when cross-functional groups discuss identical concepts using divergent dialects—such as the distinct vocabularies favored by designers, developers, product managers, and customers. Recognizing and addressing these linguistic discrepancies reduces internal friction, minimizes confusion, and fosters more cohesive collaboration across digital projects.
