Naming things in design and software development is notoriously difficult. The language teams use fundamentally shapes how they think about digital architecture and influences every conversation regarding product features, components, and user flows. This linguistic friction often leads to widespread confusion surrounding colors, icons, user interface elements, and features, creating a cascading struggle when teams attempt to establish cohesive design tokens, clean HTML classes, and intuitive programming variables.
Often, the labels assigned to elements swing to dangerous extremes. Names can become overly generic, rendering it nearly impossible for team members or users to discern their exact function or intent. Conversely, they can become too specific, leaving little room for architectural flexibility, scaling, or component reuse. Navigating this delicate balance requires an understanding of structural naming conventions, standardized taxonomies, and cross-disciplinary inspiration.
How To Name Things
Finding the right vocabulary for HTML classes, CSS properties, or JavaScript functions often demands creative inspiration from outside standard software development paradigms. Developers and designers seeking to break away from habitual phrasing frequently turn to specialized repositories designed to expand linguistic horizons. For instance, platforms like Paul Robert Lloyd’s Classnames project serve as an expansive resource jam-packed with terms that encourage out-of-the-box thinking.
The site provides meticulously curated, thematically grouped lists of words tailored for nomenclature. Users can uncover terms that effectively describe behavioral nuances, structural likeness, hierarchy, grouping, and logical association. Beyond conventional programming terminology, it introduces themed collections drawn from diverse fields such as nature, art, theater, music, architecture, fashion, and publishing, offering fresh perspectives for complex codebases.
How To Name Colors
Establishing a standardized system for identifying and referencing colors presents another persistent challenge across design and engineering teams. Addressing this friction point, David Aerne maintains an expansive repository of color names that catalogs tens of thousands of unique entries sourced from historical references and thousands of individual user contributions.
Equipped with integrated color pickers, name search functionalities, and extensive development repositories, these resources serve as a critical reference point for digital teams. By unifying how color palettes are referenced in code and design files, teams can eliminate discrepancies between visual design assets and front-end implementation, ensuring a smoother handoff and more predictable branding across multi-platform ecosystems.
How To Name Layers and Groups
Beyond code and color palettes, the internal architecture of design files requires disciplined organizational standards. Designer Javier Cuello has extensively summarized a comprehensive set of naming best practices aimed at helping teams structure layers, groups, and components in a consistent, scalable manner.
An effective name possesses a clear logical structure. It remains concise, highly meaningful, universally understood across cross-functional teams, and deliberately detached from fleeting visual properties. By evaluating clear guidelines, do’s, and don’ts, designers can refine how they categorize layout sizes, nested element groups, individual layers, and master components, ultimately streamlining collaboration between design and engineering departments.
How To Name Design Tokens
Scaling a unified design system across a massive portfolio of varied products presents an immense organizational hurdle. This challenge was confronted directly by the engineering and design teams at Intuit, the parent company behind major financial and productivity platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify their ecosystem, the organization developed a flexible design token taxonomy capable of extending far beyond a single brand theme to serve as the foundational infrastructure for a diverse array of digital products.
Detailed case studies surrounding the initiative highlight the specific pain points of legacy taxonomy systems and outline the rigorous criteria established to build a more robust architecture. By rethinking how design tokens are structured and categorized, organizations can establish a resilient foundation that accommodates future platform expansions without breaking existing token dependencies.
Frequent Names For UI Components
When teams struggle to identify the most appropriate terminology for common interface elements, analyzing existing design systems provides a reliable baseline. To prevent designers and developers from getting lost in exhaustive design system research, industry analyses like Iain Bean’s Component Gallery have systematically mapped how real-world platforms label interface components.
The collection covers numerous practical examples across more than fifty distinct UI components—ranging from standard accordions to complex visually hidden elements—while highlighting alternate names commonly used across the industry. This cross-referencing helps teams align their internal nomenclature with established user expectations and industry standards, reducing cognitive load for both creators and consumers of the system. Additional visual dictionaries, such as Name That UI, further assist practitioners in rapidly identifying and standardizing common interface patterns.
How To Name New Features
While technical nomenclature impacts internal development efficiency, the naming of user-facing features directly dictates product adoption and discoverability. Features often suffer from low engagement not due to poor utility, but because they lack intuitive discoverability. True feature adoption requires a deliberate sequence: a capability must first be discovered, subsequently understood, actively tried, learned, and finally integrated into the user’s existing daily workflow.
Effective feature names must be firmly driven by user needs and underlying problems. Rather than relying on internal corporate jargon or overly clever branding, successful feature names signal the tangible value or outcome of the capability—the core "job-to-be-done"—while tapping directly into the user’s own language. Product teams are encouraged to observe how users naturally describe a feature during qualitative research and incorporate those exact phrases into the product interface.
How To Name Variables and Taxonomy Maps
Complex multi-brand, multi-themed design systems demand rigorous hierarchical structures for variables and tokens. A prime example of this methodology comes from the Vodafone UK Design System team, whose published Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into an orchestrated system of interconnected collections.
Building upon foundational token-naming frameworks established by industry experts like Nathan Curtis, the taxonomy map illustrates the precise collections required to support enterprise systems. It maps the linear progression of tokens from foundational brand values and primitives all the way to semantic applications and page-level implementations. This structured transparency ensures that any team member can immediately deduce where a token is utilized and what it represents simply by reading its systematic name. Additional interactive frameworks, such as Romina Kavcic’s design token naming guides and inventory spreadsheets, provide practitioners with modular builders to configure customized token taxonomies spanning components, categories, states, and roles.
Naming Products or Services
At the highest level of digital architecture, naming an entire product or service requires a blend of creative exploration and strategic vetting. Comprehensive open-source repositories, such as Onym, aggregate critical tools, brainstorming methodologies, vetting frameworks, sprints, etymological insights, and specialized agencies to guide organizations through the complexities of brand nomenclature.
Wrapping Up
The ultimate success of any nomenclature system depends on mutual understanding and adoption across the entire organization. Countless hours are frequently lost when designers, developers, product managers, and users speak about the exact same system elements using completely different internal dialects. This linguistic fragmentation remains a primary catalyst for cross-functional friction and confusion.
When digital products experience lagging adoption or high friction, the root cause can frequently be traced back to unclear or misaligned naming conventions. Addressing these naming conflicts proactively and maintaining a dedicated backlog for terminology refinement helps streamline communication, bridges the gap between different departmental dialects, and empowers cross-functional teams to build and scale more cohesive digital experiences together.
