Naming is universally acknowledged as one of the hardest problems in software development and digital design. The language teams use does more than merely label elements on a screen; it fundamentally shapes how designers and developers conceptualize systems and dictates the quality of communication across multidisciplinary product teams. This deep linguistic disconnect often breeds extensive confusion regarding colors, icons, UI components, and features, ultimately spilling over into the daily struggle to name design tokens, HTML classes, and JavaScript variables effectively.
When choosing names for digital assets, practitioners frequently find themselves caught between two extremes. Names can often be far too generic, making it nearly impossible to understand what an element actually represents or does within a broader system. Conversely, names can occasionally become overly specific, leaving little room for architectural flexibility, scalability, and future reuse. Navigating this delicate balance requires a careful examination of established conventions, community-driven resources, and structured taxonomies that can bring clarity to chaotic codebases and design files.
How To Name Things
For developers and designers searching for fresh inspiration when naming HTML classes, CSS properties, or functional JavaScript components, resources like Paul Robert Lloyd’s Classnames project offer a welcome departure from conventional thinking. The platform is specifically designed to encourage teams to look beyond standard technical terminology by providing thematically grouped lists of words that can be readily applied to code architecture.
The site curates terms describing behavioral traits, similarities, hierarchical order, grouping methodologies, and categorical associations. Furthermore, it introduces rich, thematic collections drawn from domains that do not instantly cross a developer’s mind during a coding sprint—ranging from nature, art, theater, and music to architecture, fashion, and publishing. By broadening the linguistic palette available to creators, such resources help teams establish more evocative and meaningful identifiers without relying on tired, repetitive naming conventions.
How To Name Colors
Choosing the right name for a specific color value has long vexed both front-end engineers and UI designers working on complex theme engines. Fortunately, David Aerne maintains a massive repository of color names known simply as color-names, which currently catalogs over 30,000 unique color designations sourced from various historical references and thousands of individual community contributions.
This expansive repository is accompanied by interactive tools such as color pickers and name searches, including related projects like Color Parrot. Such comprehensive databases serve as invaluable references for teams striving to move away from rigid, mathematical hex codes or simplistic shade scales toward semantic color identifiers that integrate seamlessly into modern design systems.
How To Name Layers and Groups
Establishing consistency within a design file is just as critical as maintaining clean code in production. Designer Javier Cuello has synthesized a robust set of naming best practices aimed at helping teams structure layers, groups, and components in a scalable, predictable manner.
According to Cuello’s guidelines, an effective name possesses a logical structure, remains concise yet meaningful, is universally understood across the organization, and completely avoids relying on volatile visual properties like specific pixel dimensions or raw color values. By studying comprehensive do’s and don’ts, designers can eliminate the common clutter found in design files, ensuring that handoffs to engineering teams proceed smoothly and without ambiguity.
How To Name Design Tokens
Building a flexible design token taxonomy that successfully scales across a diverse portfolio of products is a monumental architectural challenge. This exact hurdle was confronted by the design system team at Intuit, the parent company behind household financial and productivity products such as Mailchimp, QuickBooks, TurboTax, and Mint. To solve this, the organization engineered a versatile token system capable of transcending individual brand themes to function as a unified foundational architecture.
In an in-depth case study, Nate Baldwin shared vital insights into the creation of Intuit’s design token taxonomy, detailing the inherent pain points of their legacy systems, the rigorous criteria established for the redesign, and the eventual implementation process. These lessons provide a blueprint for organizations aiming to build robust, multi-brand token structures that can withstand rapid corporate growth and frequent visual rebrandings.
Frequent Names For UI Components
When teams struggle to identify the correct nomenclature for standard user interface elements, one of the most effective strategies is to look outward at how established design systems solve the same problem. To spare practitioners from falling down an endless research rabbit hole, Iain Bean developed the Component Gallery, an exhaustive collection that aggregates interface components drawn directly from real-world design systems.
The repository catalogs examples and alternative names for more than 50 distinct UI components—ranging from basic structural elements like accordions to accessibility-focused utilities like visually hidden text. Supplementary tools like Name That UI, a visual dictionary of common interface components, further assist practitioners in standardizing their component libraries around widely recognized industry terms.
How To Name New Features
Low feature adoption is frequently blamed on engineering flaws or lack of user interest, but root cause analysis often reveals that the primary culprit is poor discoverability driven by confusing nomenclature. Feature adoption requires a deliberate journey: a capability must first be discovered, subsequently understood, actively tried, thoroughly learned, and finally integrated into the user’s existing daily workflow. UX writer Erin Gannon addressed this challenge in a practical guide focused on aligning feature names with user expectations.
Effective feature names must be rooted directly in genuine user needs and problem spaces. Rather than relying on clever internal jargon or corporate codenames, successful features signal their tangible value and ultimate outcome by adopting the language users themselves naturally use. Gannon recommends actively asking users to describe a feature in their own words and incorporating that exact vocabulary into the product interface.
How To Name Variables (Taxonomy Map)
Managing a complex, multi-brand, and multi-themed ecosystem requires an exceptionally disciplined approach to variable management. A prime example of this methodology comes from the Vodafone UK Design System team, whose published Variables Taxonomy Map meticulously breaks down the anatomy and categorization of design tokens into an orchestrated hierarchy of collections.
Building upon Nathan Curtis’s foundational work on token architecture, the Vodafone map outlines the four distinct collections necessary to support a modern enterprise system—tracing token relationships smoothly from foundational brand primitives up to semantic rules and page-level applications. This structured approach ensures that any team member can immediately understand where a token is utilized and what it represents simply by reading its identifier. Additional resources, such as Romina Kavcic’s design token naming guide and inventory spreadsheets, offer further tactical frameworks for structuring tokens across components, categories, states, and roles without losing track of organizational changes.
Naming Products or Services
Beyond interface elements and code variables, naming entire products or services represents a high-stakes endeavor that requires rigorous brainstorming, market vetting, and linguistic research. Open-source repositories like Onym aggregate a wide array of tools, methodologies, sprinting frameworks, etymological resources, and cautionary tales to guide creators through the complexities of brand naming.
Wrapping Up
Ultimately, the most successful name is one that is universally understood and actively adopted by both the internal product team and the end users. Countless hours are frequently wasted in product development cycles because designers, developers, product managers, and users speak entirely different dialects while attempting to describe the exact same underlying concept.
Addressing these linguistic disparities and identifying potential naming conflicts early in the design phase can significantly reduce friction and confusion. By treating naming as an intentional architectural discipline rather than an afterthought, organizations can streamline their workflows and foster smoother collaboration across every stage of the product lifecycle.
