Naming things in design and software development is notoriously difficult. The language teams use shapes not only how they think about digital products, but also the conversations they have during the creation process. This underlying challenge is often the root cause of frequent confusion surrounding colors, icons, user interface components, and features. It is precisely why designers and developers alike struggle to establish consistent names for design tokens, HTML classes, and variables.
Often, the names chosen during the development lifecycle fall into two problematic extremes. Sometimes they are far too generic, making it nearly impossible to understand what is actually meant or intended. At other times, they are overly specific, boxing the team into a corner and leaving little room for flexibility, scalability, and future reuse. Finding the right balance requires a deliberate look at established naming conventions, strategies, and community-driven resources that help bridge the gap between different departmental dialects.
How To Name Things
When developers and designers look for inspiration for naming HTML classes, CSS properties, or JavaScript functions, resources like Classnames offer a wonderful starting point designed to get professionals thinking outside the box. The platform provides thematically grouped lists of words that are ideal for codebases and design systems. Users can discover terms that describe behavior, likeness between elements, order, grouping, and association, alongside themed collections from nature, art, theater, music, architecture, fashion, and publishing that might not instantly come to mind during standard technical execution.
This challenge of bridging creative vocabulary with technical structure extends heavily into visual elements and color systems. Choosing the right name for a specific color can often stall a project’s momentum. Fortunately, David Aerne maintains a massive repository of color names containing tens of unique entries sourced from various references and thousands of user contributions. Accompanied by interactive color pickers and name search utilities, this repository serves as a fantastic, reliable reference to keep nearby when establishing a project’s palette.
How To Name Layers and Groups
Beyond code and color, the organization of design files requires strict discipline. A well-structured approach to naming layers, groups, and components is essential for maintaining consistency as a product scales. Javier Cuello has summarized key naming best practices that highlight what makes an effective identifier in collaborative design environments. According to these guidelines, a strong name should feature a logical structure, remain short and meaningful, be universally understood across the team, and avoid direct reliance on transient visual properties. Exploring the fine details of do’s and don’ts helps teams navigate the complexities of labeling sizes, colors, groups, and components uniformly.
Scaling this consistency across massive, multi-product organizations presents an even greater hurdle. This was the exact challenge faced by the team at Intuit, the parent company behind household names like Mailchimp, QuickBooks, TurboTax, and Mint. The organization needed to build a flexible design token taxonomy capable of working across vastly different products while extending far beyond a single brand theme. Nate Baldwin detailed this journey in a comprehensive case study, outlining the pain points of their legacy taxonomy, the criteria established for the new system, and the valuable takeaways derived from building a robust, enterprise-grade token architecture.
Frequent Names For UI Components
When teams struggle with what to call specific interface elements, analyzing how other organizations solve the problem is often the most pragmatic first step. Rather than getting lost down the rabbit hole of disparate design systems, Iain Bean compiled the Component Gallery, a comprehensive collection that features real-world examples for more than fifty UI components. Ranging from accordions to visually hidden elements, the gallery documents the various aliases and standard names that components go by across the industry, complemented by visual dictionaries like Name That UI.
Naming brand new features, however, introduces an entirely different set of behavioral and psychological challenges. Features often suffer from low user adoption simply due to poor discoverability and misaligned terminology. Erin Gannon explored this dynamic in a practical guide examining how features must first be discovered, understood, tried, learned, and eventually integrated into a user’s existing workflow. The research emphasizes that effective feature names should be driven by user needs and problems, signaling the value or outcome—the job to be done—while actively tapping into the user’s own language rather than internal corporate jargon.
How To Name Variables and Design Tokens
As design systems grow increasingly complex, structuring variables requires meticulous planning. A prime example of this level of organization comes from the Vodafone UK Design System team, whose published Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into a well-orchestrated system of collections. Building upon foundational work by Nathan Curtis, the map illustrates the necessary collections required to support a multi-brand system—transitioning smoothly from brand foundations and primitives to semantics and pages. This interconnected structure ensures that anyone inspecting a token can immediately discern its origin, purpose, and application simply from its name.
Further expanding on these methodologies, Romina Kavcic developed interactive tools and inventory spreadsheets designed to help teams configure their own token naming structures. By breaking down structures into components, categories, states, and roles across a multi-level spreadsheet, designers can maintain a bird’s-eye view of their token architecture, effortlessly adding themes and modes without losing track of their data.
Naming Products or Services
Moving from internal components to consumer-facing offerings, naming products and services demands an entirely different creative and strategic approach. Open-source repositories like Onym serve as centralized hubs organizing tools, brainstorming methodologies, vetting techniques, sprints, etymologies, and industry guides to help creators navigate the naming process successfully.
Ultimately, the right name is consistently defined as one that is clearly understood and actively used by both the internal team and the end users. A significant amount of time and productivity is frequently lost when different departments—designers, developers, product managers, and users—discuss the exact same concept using entirely different dialects. Recognizing that low feature adoption or cross-team friction can often stem from naming conflicts allows organizations to address these pain points proactively, reducing confusion and fostering a more cohesive collaborative environment.
