Naming things remains one of the most persistent and vexing challenges in software development and digital design. The language teams choose not only shapes how they conceptualize technical and visual elements, but it also dictates the quality of the conversations surrounding them. This fundamental communication gap is why widespread confusion frequently arises over colors, icons, user interface components, and features. It is also why professionals continuously struggle to establish cohesive names for design tokens, HTML classes, and code variables.
Often, the labels selected are far too generic, making it difficult to discern their exact purpose or context. Conversely, labels can sometimes be overly specific, inadvertently restricting flexibility and hindering future reuse. Resolving this tension requires examining how industry leaders approach naming conventions, structure, and taxonomy across modern digital products.
How To Name Things
For developers and designers seeking fresh inspiration when naming HTML classes, CSS properties, or JavaScript functions, resources like Paul Robert Lloyd’s Classnames project offer a wealth of creative alternatives designed to encourage thinking outside conventional confines. The platform provides thematically grouped lists of words categorized by behavior, likeness, order, grouping, and association.
Beyond standard technical terminology, the resource includes curated collections drawn from fields that rarely intersect directly with code, such as nature, art, theater, music, architecture, fashion, and publishing. By broadening the vocabulary available to creators, such tools help prevent the repetition of monotonous or ambiguous identifiers in stylesheets and application codebases.
How To Name Colors
Establishing a reliable and intuitive naming convention for color palettes presents its own unique set of obstacles. To address this, developer David Aerne maintains an extensive repository of color names known as Color Names, which currently features more than thirty thousand unique identifiers gathered from a wide array of references and thousands of community contributions.
The repository includes integrated color pickers and name search functionality, serving as an invaluable reference tool for designers and front-end engineers alike. By relying on established, community-driven color dictionaries, teams can avoid arbitrary hex-code naming schemes and instead adopt descriptive, recognizable color tokens that scale across complex multi-brand applications.
How To Name Layers and Groups
Establishing consistency within design files is just as critical as maintaining clean codebases. Javier Cuello recently outlined a comprehensive set of design best practices aimed at standardizing how layers, groups, and components are organized and labeled within collaborative environments like Figma.
According to these guidelines, an effective name possesses a logical structure while remaining concise, meaningful, and universally understood across cross-functional teams. Crucially, Cuello emphasizes that names should avoid referencing fleeting visual properties that are prone to change during iterations. By following established do’s and don’ts, designers can eliminate the clutter and ambiguity that often plagues shared design systems.
How To Name Design Tokens
Scaling a design system across multiple enterprise products introduces a complex architectural challenge. This exact hurdle was confronted by the design system team at Intuit, the parent organization behind widely used platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify these diverse offerings, the team engineered a flexible design token taxonomy capable of extending far beyond any single brand theme to serve as a foundational infrastructure for dozens of interconnected products.
In a detailed case study, Nate Baldwin shared critical insights into the development of Intuit’s design token architecture. The documentation highlights the primary pain points of legacy taxonomy systems, outlines the strict criteria established for the modern replacement, and details the implementation process. These lessons provide valuable blueprints for organizations seeking to construct robust, resilient token taxonomies of their own.
Frequent Names For UI Components
When teams encounter roadblocks while determining nomenclature for interface elements, examining existing design systems offers an efficient path forward. To spare practitioners from navigating the sprawling landscape of disparate design libraries, Iain Bean compiled the Component Gallery, an exhaustive index of interface components drawn from real-world products.
The collection aggregates implementation examples and alternative nomenclature for more than fifty distinct user interface components, ranging from foundational elements like accordions to specialized patterns such as visually hidden utility classes. Additionally, complementary resources like Name That UI function as visual dictionaries to help bridge the terminology gap between nascent designers and experienced engineers.
How To Name New Features
Low feature adoption rates within software products can frequently be traced back to poor discoverability and ambiguous naming. True feature adoption requires a deliberate sequence of user behaviors: first, the functionality must be discovered; next, it must be understood; then, it must be tried and learned; and finally, it must be integrated into the user’s existing workflow.
In her practical guide on the subject, product strategist Erin Gannon emphasizes that successful feature names must be rooted directly in user needs and problem-solving. Rather than relying on internal corporate jargon, names should signal the tangible value or outcome of a feature—its core job-to-be-done—by adopting the exact vocabulary used by the users themselves. Soliciting feedback and listening closely to how users describe tasks in their own words ensures that feature titles resonate immediately upon release.
How To Name Variables and Taxonomy Maps
Managing nomenclature across enterprise-scale ecosystems requires meticulous structural planning. A prime example of this methodology is demonstrated by the Vodafone UK Design System team, whose published Variables Taxonomy Map illustrates the intricate anatomy and categorization required for a multi-brand, multi-themed architecture.
The map breaks down the necessary collections and connections between tokens, guiding teams smoothly from foundational brand primitives up to semantic layer variables and page-level applications. Building upon foundational frameworks established by industry experts like Nathan Curtis, this structured approach enables any team member to instantly understand a token’s origin, intended use case, and functional scope purely by reading its identifier. Additional community-driven kits and resources continue to emerge, offering alternative models for token organization.
Design Token Naming Guide and Inventory
To assist practitioners in mastering token architecture, Romina Kavcic developed an interactive guide and configuration tool focused on design token naming structures. The utility helps creators navigate categories, components, states, and roles to establish rigorous and predictable naming conventions.
Complementing this builder is a structured design token inventory spreadsheet designed to provide a bird’s-eye view of an entire token library across four distinct hierarchy levels. The layout allows teams to seamlessly append rows, themes, and presentation modes while maintaining the ability to filter and sort tokens without losing track of dependencies.
Naming Products or Services
Venturing beyond internal code and design tokens, naming an external product or service presents distinct branding and marketing hurdles. To assist with this creative endeavor, the open-source repository Onym organizes a curated selection of tools, brainstorming methodologies, vetting frameworks, sprints, and etymological guides. By compiling academic references, cautionary industry tales, and specialized agency directories, the directory encourages multidisciplinary teams to explore diverse paths toward brand identity.
Wrapping Up
Ultimately, the most effective name is one that is universally understood and actively utilized by both the immediate product team and the end users. Substantial engineering and design hours are frequently lost simply because stakeholders discuss identical concepts using divergent dialects—the designer’s terminology, the developer’s syntax, the product manager’s vocabulary, and the user’s everyday language.
Identifying and resolving these nomenclature conflicts prevents persistent friction and empowers cross-functional groups to collaborate with clarity and precision.
