In the fast-paced world of digital product development, few challenges are as universally acknowledged yet perpetually frustrating as the art of naming. Whether it is choosing a variable name in a complex stylesheet, designating a brand-new design token, or figuring out what to call an innovative software feature, the vocabulary professionals choose shapes not only how they conceptualize products but also how they communicate across cross-functional teams.
Language creates the mental models through which we understand user interfaces, components, and codebases. When terminology breaks down, confusion inevitably follows. Teams frequently struggle with names that are either too generic to convey precise meaning or overly specific, stripping away the necessary flexibility and reuse potential required for scalable systems. This tension has sparked a broader conversation within the global design and engineering community, leading to the creation of robust new resources, repositories, and taxonomies aimed at bringing clarity to digital nomenclature.
How To Name Things
The struggle to name HTML classes, CSS properties, and JavaScript functions has long driven developers to seek inspiration outside standard programming conventions. To help bridge this gap, resources like Paul Robert Lloyd’s Classnames have emerged as vital tools designed to push practitioners out of traditional naming loops.
Rather than relying on tired, repetitive descriptors, the platform provides thematically grouped lists of words categorized by behavior, likeness, order, grouping, and association. It also introduces unexpected thematic collections drawn from nature, art, theater, music, architecture, fashion, and publishing. By tapping into vocabularies traditionally divorced from software engineering, developers can find descriptive, evocative terms that make their codebases more expressive and maintainable.
How To Name Colors
Color naming has historically been an arbitrary and subjective process, often resulting in inconsistent hex codes and disjointed variable names across large design systems. To address this, developer David Aerne maintains a massive repository of color names that currently catalogs over 30,000 unique designations gathered from historical references and thousands of user contributions.
Accompanied by interactive tools such as color pickers and name search utilities, the repository serves as a critical reference for designers and developers alike. Having a standardized, expansive vocabulary for color takes the guesswork out of token creation, ensuring that teams can reference hues consistently without resorting to confusing numerical scales that lack semantic context.
How To Name Layers and Groups
Beyond code and color, the structural organization of design files requires rigorous discipline. Javier Cuello recently outlined a comprehensive set of naming best practices aimed at bringing consistency and scalability to digital layers, groups, and components.
According to Cuello, an effective name possesses a clear logical structure: it is concise, deeply meaningful, universally understood within the organization, and detached from transient visual properties. By following established dos and don’ts, design teams can avoid the chaos of unorganized artboards and nested groups, streamlining collaboration between designers handing off work and developers inspecting design specifications.
How To Name Design Tokens
As enterprise design systems scale across multiple brands and platforms, establishing a flexible design token taxonomy becomes an urgent priority. A prominent example of this challenge occurred within Intuit, the parent organization behind major financial and productivity platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. The company needed a unified token architecture that could transcend individual brand identities and serve as a resilient foundation across a sprawling ecosystem of digital products.
Nate Baldwin detailed the creation of this taxonomy in an extensive case study, breaking down the pain points of legacy systems and outlining the strategic criteria required for a modern, robust architecture. Similarly, the Vodafone UK Design System team addressed the complexity of a multi-brand, multi-themed environment by releasing their Variables Taxonomy Map. Built upon foundational work by Nathan Curtis, the Vodafone map illustrates the four core collections necessary to support a modern system—spanning from brand primitives and semantics down to page-level implementation. These frameworks ensure that any team member can instantly determine where a token is utilized and what it represents simply by reading its identifier.
Additional tools, such as Romina Kavcic’s Design Token Naming Guide and accompanying inventory spreadsheets, offer practitioners interactive frameworks to configure their own naming structures, incorporating components, categories, states, and roles without losing track of dependencies as systems evolve.
Frequent Names For UI Components
When teams find themselves stuck in a naming deadlock, looking at established design systems offers a reliable roadmap. To save practitioners hours of independent research, Iain Bean built the Component Gallery, a comprehensive index cataloging real-world design systems.
The collection features practical examples and alternative nomenclature for more than 50 standard interface components—ranging from common patterns like accordions to accessibility-focused utilities like visually hidden elements. Complementary tools like Name That UI provide a visual dictionary of interface elements, helping both junior and senior practitioners align on industry-standard terminology.
How To Name New Features
While internal architecture relies on precise technical language, customer-facing features demand an entirely different approach. Low feature adoption is frequently a symptom of poor discoverability and confusing nomenclature rather than a flaw in the product itself. True feature adoption requires a deliberate journey: discovery, comprehension, trial, mastery, and eventual integration into a user’s daily workflow.
In her practical guide on feature naming, Erin Gannon emphasizes that successful names are fundamentally driven by user needs and the specific "job-to-be-done." Rather than relying on internal company jargon or overly clever branding, product teams are encouraged to listen closely to how users describe their own problems in their native language and integrate those exact terms into the product’s feature set.
Naming Products and Services
At the highest level of nomenclature sits the challenge of naming an entire product, service, or company. For teams embarking on this high-stakes journey, open-source repositories like Onym serve as comprehensive hubs for brainstorming methodologies, vetting frameworks, etymological research, and industry guides. By organizing tools and professional resources into a single location, these guides help organizations navigate the creative and strategic complexities of brand identity.
Wrapping Up
Ultimately, the most effective name is the one that is universally understood and actively utilized by both the internal product team and the end user. Countless hours are lost across the technology sector when designers, developers, product managers, and users speak about the exact same underlying concept using entirely different dialects.
Addressing these linguistic divides and proactively managing naming conflicts within a dedicated backlog can drastically reduce daily friction. By treating nomenclature as an essential pillar of system architecture rather than an afterthought, organizations can foster smoother collaboration and build more intuitive, cohesive digital experiences.
