Naming things is widely acknowledged as one of the hardest challenges in software development, design systems, and product management. The language teams use not only shapes how they conceptualize digital products but also dictates the conversations they have about codebases, user interfaces, and feature sets. This friction often results in persistent confusion surrounding colors, icons, UI components, and product features, subsequently translating into struggles when defining design tokens, HTML classes, and variables.
Often, the chosen names fall into one of two problematic extremes: they are either far too generic, making it nearly impossible to understand their precise intent, or they are excessively specific, leaving little room for flexibility, scalability, and code reuse. Navigating this delicate balance requires an understanding of established conventions and a willingness to explore cross-disciplinary vocabularies. Industry professionals are increasingly turning to dedicated resources, open-source repositories, and comprehensive naming taxonomies to resolve these long-standing communication breakdowns across design and engineering teams.
How To Name Things
Finding inspiration beyond traditional technical terminology can drastically improve how developers and designers name HTML classes, CSS properties, and JavaScript functions. Resources like Classnames, a project curated by Paul Robert Lloyd, offer a departure from standard nomenclature by prompting creators to think outside the traditional development box.
The platform provides thematically grouped lists of words tailored specifically for naming elements based on behavioral traits, structural likeness, hierarchy, grouping, and associations. Beyond standard technical descriptors, it incorporates rich thematic collections drawn from nature, art, theater, music, architecture, fashion, and publishing. By tapping into these diverse domains, teams can establish more evocative and meaningful identifiers that transcend sterile, unimaginative code.
How To Name Colors
Establishing a clear and scalable color naming convention presents another recurring hurdle for digital teams. Managing color tokens effectively requires a shared vocabulary that avoids subjective terms like "darker blue" or "bright red." David Aerne addresses this challenge by maintaining a massive, community-driven repository of color names containing over 30,000 unique entries compiled from various references and thousands of user submissions.
Integrated tools like Color Parrot allow contributors and developers to instantly discover or assign evocative names to specific hex codes. Supported by intuitive color pickers and name-search functionalities, these repositories serve as invaluable references for keeping color palettes organized, standardized, and easily digestible across multidisciplinary design and engineering workflows.
How To Name Layers and Groups
Maintaining cleanliness and structural integrity within design files is critical for scalable product development. Javier Cuello has formalized a comprehensive set of naming best practices aimed at standardizing how designers structure layers, groups, and components.
According to these guidelines, an effective name possesses a clear logical structure, remains concise yet meaningful, is universally understood across the team, and avoids direct reliance on transient visual properties. By establishing clear do’s and don’ts, these practices help mitigate the chaos often found in large design files, ensuring that sizing conventions, color applications, and component hierarchies remain consistent as products scale.
How To Name Design Tokens
As organizations grow and manage multiple brands simultaneously, establishing a flexible design token taxonomy becomes an enterprise-level necessity. This exact challenge was faced by the team at Intuit, the parent company behind major financial and productivity platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify their vast product ecosystem, the company engineered a flexible token system designed to extend far beyond individual brand themes.
In a detailed case study, Nate Baldwin shared the behind-the-scenes evolution of Intuit’s design token taxonomy. The documentation outlines the critical pain points of their legacy systems, the rigorous criteria established for the new architecture, and the implementation strategies required to build a robust, enterprise-grade token foundation capable of supporting diverse product requirements.
Frequent Names For UI Components
When teams struggle to name common interface elements, analyzing established design systems provides an immediate and reliable shortcut. To prevent designers and developers from getting lost down the rabbit hole of disparate naming conventions, Iain Bean developed the Component Gallery.
This comprehensive archive aggregates interface components sourced directly from real-world design systems. Featuring dozens of common UI patterns—ranging from simple accordions to complex visually hidden elements—the gallery documents the various aliases and secondary names each component goes by across different organizations, serving as a practical reference for cross-functional alignment. Complementary visual dictionaries like Name That UI further assist teams in visually identifying and standardizing common interface nomenclature.
How To Name New Features
Low feature adoption rates within digital products are frequently tied to poor discoverability and unclear naming conventions. True feature adoption is a gradual process that requires a user to first discover a capability, understand its utility, test it out, learn its mechanics, and eventually integrate it into their existing daily workflows. Erin Gannon has explored this dynamic in depth, offering practical guidelines on how to name features so that users can actually discover, understand, and use them.
Effective feature names should be firmly rooted in user needs and specific problem spaces. Rather than relying on internal corporate jargon, successful feature names signal the tangible value or outcome of the tool—aligning closely with the user’s "job-to-be-done." Gannon emphasizes the importance of listening to how users naturally describe a feature in their own vernacular and directly incorporating that language into the product’s interface.
How To Name Variables (Taxonomy Map)
Complex multi-brand and multi-themed design systems demand rigorous variable taxonomies to prevent styling conflicts. A notable example of this structured approach comes from the Vodafone UK Design System team, whose published Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into an orderly hierarchy of collections.
Building upon foundational work by design systems expert Nathan Curtis, Vodafone’s mapping structure outlines four distinct collections necessary to support a modern multi-brand architecture—spanning from brand primitives and semantic tokens to specific page applications. This structured approach allows team members to instantly trace where a specific token is utilized and what it represents based entirely on its name. Additional resources, such as Romina Kavcic’s Design Token Naming Guide and accompanying token inventory spreadsheets, offer further structured frameworks to help organizations audit, filter, and scale their token architectures without losing administrative control.
Naming Products or Services
Venturing beyond internal codebases and design systems, choosing an external name for a new product or service remains a high-stakes undertaking. Open-source repositories like Onym aggregate essential tools, methodologies, and frameworks for brainstorming, vetting, and researching brand names. By organizing guides, etymological resources, and cautionary case studies into a single hub, these initiatives help product teams navigate the complex landscape of market positioning and nomenclature.
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. A significant amount of operational time is routinely lost when designers, developers, product managers, and users speak about the exact same functionality using entirely different internal dialects. This linguistic fragmentation is a primary driver of workplace frustration and architectural confusion.
When product metrics indicate low feature adoption or cross-team collaboration falters, the root cause is frequently traced back to ambiguous or conflicting nomenclature. By actively auditing naming conventions, documenting decisions, and addressing discrepancies in a dedicated backlog, organizations can significantly reduce friction and build more cohesive digital experiences.
