Naming things is universally acknowledged as one of the hardest challenges in software development and digital design. The language teams use does more than simply label elements; it actively shapes how concepts are understood, dictates the direction of crucial product discussions, and ultimately determines whether codebases and design systems remain maintainable or descend into chaos.
Across the industry, this linguistic friction manifests as widespread confusion over colors, icons, user interface components, and features. It is the underlying reason why professionals frequently struggle to establish clear, scalable naming conventions for design tokens, HTML classes, and programmatic variables. When names are chosen poorly, they often swing to extremes: they are either too generic, making it nearly impossible to understand their precise intent, or they are too specific, leaving little room for flexibility, extension, and reuse across multi-brand environments.
To address these persistent hurdles, a wave of new resources, open-source repositories, and strategic frameworks has emerged to help designers, developers, and product managers bridge the communicative gaps that often divide multidisciplinary teams.
How to Name Things Beyond Code
When developers and designers search for fresh inspiration when naming HTML classes, CSS properties, or JavaScript functions, traditional vocabulary can often feel restrictive. To encourage professionals to think outside the traditional boxes of software syntax, web developer Paul Robert Lloyd created Classnames, a resource jam-packed with alternative ideas.
The platform provides thematically grouped lists of words tailored specifically for structured naming. Users can browse terms that describe various kinds of behavior, likeness, order, grouping, and association. More uniquely, it offers themed collections of words drawn from fields that do not instantly come to mind in a coding context, including nature, art, theater, music, architecture, fashion, and publishing. By broadening the linguistic palette, teams can find evocative and precise terms that prevent naming collisions and bring clarity to complex architectures.
Finding Precision in Color Taxonomies
Color nomenclature has long plagued digital creators. Deciding what to call a specific shade or tint often leads to subjective debates that stall production. Fortunately, developer 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 user contributions.
Accompanied by a color picker and name search tool originally popularized via social media as Color Parrot, the repository serves as an invaluable reference library for teams trying to establish systemic color tokens. By tapping into a standardized yet expansive vocabulary, projects can avoid vague descriptors like "blue-light" in favor of more robust, scalable taxonomies.
Structuring Layers, Groups, and Components
In the realm of interface design, inconsistent layer and group naming can quickly render a design file unnavigable for engineers and fellow designers alike. Javier Cuello recently summarized a comprehensive set of naming best practices designed to bring consistency and scalability to layers, groups, and components.
According to Cuello, an effective name possesses a logical structure, remains concise, carries clear meaning, is universally understood across the team, and avoids being tied directly to temporary visual properties. By establishing clear do’s and don’ts, these guidelines help practitioners navigate the fine details required when naming sizes, colors, structural groups, and reusable components within collaborative workspace tools like Figma.
Scaling Design Tokens Across Complex Organizations
One of the most formidable modern challenges is building a flexible design token taxonomy that functions seamlessly across multiple products, brands, and themes. This exact obstacle was recently tackled by the design systems team at Intuit, the parent company behind major financial and productivity platforms such as Mailchimp, QuickBooks, TurboTax, and Mint.
Faced with the limitations of an aging taxonomy, the team engineered a flexible token system designed to extend far beyond a single brand theme, establishing a foundational architecture capable of supporting a wide array of distinct digital products. Nate Baldwin documented this extensive overhaul in a detailed case study, outlining the core pain points of the legacy system, the strict criteria defined for the new architecture, and the strategic rollout that followed. The insights provide a blueprint for organizations attempting to construct robust, enterprise-grade token taxonomies.
Similarly, the Vodafone UK Design System team addressed multi-brand complexity by releasing a comprehensive Variables Taxonomy Map on Figma. Built upon foundational work by Nathan Curtis, the Vodafone map breaks down the anatomy and categorization of design tokens into four distinct, interconnected collections—ranging from brand primitives to semantic applications and page-level variables. This structure ensures that any team member can immediately deduce where a token is utilized and what it represents simply by reading its name.
For practitioners seeking further implementation tools, Romina Kavcic has developed an interactive design token naming guide and builder, complemented by an inventory spreadsheet featuring a four-tiered structure designed to give teams a bird’s-eye view of their token architecture without losing track of themes and modes.
Establishing Common Ground for UI Components
When teams struggle to name interface elements, examining established patterns in existing design systems is often the most effective starting point. To save practitioners from endlessly researching disparate libraries, Iain Bean developed the Component Gallery.
This comprehensive collection gathers interface components from real-world design systems, providing concrete examples for more than fifty distinct UI components—ranging from basic accordions to hidden accessibility elements—while documenting the alternative names these components frequently go by in different organizations. The resource is complemented by visual dictionaries like Name That UI, which help align cross-functional vocabulary.
Unlocking Feature Discovery Through User Language
Beyond code and design tokens, the names given to newly launched product features play a critical role in user adoption. Features often suffer from low engagement not because they lack utility, but due to poor discoverability and confusing nomenclature. Feature adoption requires a deliberate progression: a capability must first be discovered, then understood, tried, learned, and eventually integrated into a user’s existing workflow.
In a practical guide on feature naming, UX writer Erin Gannon emphasizes that successful names are fundamentally driven by user needs and problems. Rather than relying on internal jargon or clever branding, feature names should signal the concrete value or outcome of the capability—the job-to-be-done—by directly tapping into the language users employ themselves. Gannon advises teams to prompt users to describe features in their own words and to integrate those natural expressions into the product’s interface.
Structuring Product and Service Nomenclature
For teams tasked with naming entirely new products or services, open-source repositories like Onym provide structured methodologies, brainstorming frameworks, vetting tools, and etymological guides. By organizing resources ranging from academic literature to professional naming agencies, the platform encourages divergent thinking during the foundational phases of product development.
Ultimately, industry experts note that the correct name is simply the one that is universally understood and actively utilized by both the internal team and the end users. A significant amount of time and productivity is frequently lost when multidisciplinary teams discuss identical concepts using conflicting dialects—the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect. Recognizing and resolving these linguistic disconnects remains one of the most effective ways to reduce organizational friction and foster seamless collaboration across the web development lifecycle.
