Executive Overview
In the realm of software engineering, digital product design, and architecture, an old adage persists: "There are only two hard things in Computer Science: cache invalidation and naming things." While humorously stated by Martin Fowler, this sentiment strikes at the very heart of daily friction in cross-functional product teams.
Naming is hard because language does not merely describe reality; it actively shapes how we conceptualize problems, structure codebases, and converse with stakeholders. When a designer, a front-end developer, a product manager, and an end-user each speak a different semantic dialect for the exact same UI element, friction ensues. This linguistic fragmentation results in what modern product organizations experience as systemic confusion, delayed feature adoption, bloat in component libraries, and mountains of technical debt.
The consequences of poor nomenclature stretch far beyond aesthetic preferences or code cleanliness. Low feature adoption is frequently tied not to poor functionality, but to poor discoverability rooted in confusing, ambiguous, or overly technical naming. If a user cannot immediately understand what a feature does or how it fits into their workflow using their own mental models, they will abandon it. Similarly, when design tokens or HTML classes swing too far toward the generic—or conversely, become too rigidly specific—they lose flexibility, scalability, and reusability.
This definitive guide synthesizes the industry’s most powerful practical resources, foundational taxonomies, naming conventions, and structural frameworks. Whether you are struggling to name a nuanced CSS class, architecting a multi-brand design token system, establishing a cohesive layer hierarchy in Figma, or christening a brand-new user-facing feature, the following insights will transform how your team communicates, builds, and scales digital products.
Detailed Chronology: The Evolution of Naming Best Practices in Digital Design
To understand how the tech industry arrived at our current ecosystem of advanced token taxonomies and centralized component galleries, we must trace the evolution of how we name digital artifacts.
Phase One: The Wild West of Web Development (Late 1990s – Late 2000s)
In the early days of the web, naming was largely ad-hoc. Developers created HTML classes and CSS IDs based on immediate visual appearance rather than semantic meaning (e.g., .red-box or .bold-text). As websites scaled into complex applications, this visual-first approach broke down entirely. Changing a brand color meant scouring thousands of lines of CSS to manually update every instance of .red-box to .blue-box, giving birth to widespread style sheet maintenance nightmares.
Phase Two: The Rise of Methodology and Standardization (2010s)
Recognizing the structural chaos of unstructured naming, the industry responded with methodology-driven frameworks. Systems like BEM (Block, Element, Modifier), SMACSS, and OOCSS emerged to impose rigorous structural rules on CSS classes. Simultaneously, design tooling matured. Sketch and early Figma popularized nested layer panels, forcing designers to grapple with how layers, artboards, and symbol groups were named. However, without centralized dictionaries, team-specific silos still dominated.
Phase Three: Design Systems and the Token Era (Present Day)
Today, the digital product landscape is defined by design systems—comprehensive ecosystems that bridge the gap between design tools and codebases. This era introduced design tokens (the atomic variables holding visual design attributes like colors, spacing, and typography) and multi-brand architecture. Naming is no longer just about writing clean code; it is about establishing a shared taxonomy that translates seamlessly across Figma libraries, token JSON files, multi-platform applications, and marketing portals. Modern nomenclature has evolved into a strategic discipline requiring cross-disciplinary consensus.
Supporting Context & Metrics: Unlocking the Toolbox for Universal Naming
Navigating the naming labyrinth requires looking outside your immediate team’s bubble. Fortunately, the web design and engineering community has cultivated an incredible array of open-source resources, repositories, and directories designed to spark inspiration and impose rigorous structure.
1. Breaking Out of Code-Brain: Inspirational Vocabularies
When you are trapped inside a recursive loop of technical terms—using variations of container, wrapper, box, and item—you need to think outside the box.
- Classnames: Maintained by Paul Robert Lloyd, Classnames is an exceptional resource that provides thematically grouped lists of words tailored for naming HTML classes, CSS properties, and JavaScript functions. Rather than defaulting to sterile developer terminology, the site curates words categorized by behavior, likeness, order, grouping, and association. Crucially, it introduces themed collections drawn from nature, art, theater, music, architecture, fashion, and publishing, enabling semantic richness in your architecture.
2. Taming the Color Palette: Quantitative Color Nomenclature
Choosing the right name for a custom color token is notoriously subjective. Should a hex code be #3178C6 or azure-blue or brand-primary-alt?
- Color Names Repository: David Aerne maintains a massive repository comprising over 30,355 unique color names sourced from various references and thousands of user contributions.
- Color Parrot: Linked with tools like
color.pizza, this repository includes interactive pickers and name searches that take the guesswork out of color tokens, ensuring your team has an objective, shared vocabulary for chromatic design decisions.
3. Structuring Layers, Groups, and Components in Design Tools
In design tools like Figma, messy layers destroy scalability. Javier Cuello has outlined a comprehensive set of naming best practices for layers, groups, and components.
According to Cuello, an effective name possesses a logical structure, remains concise yet meaningful, is universally understood across the team, and avoids direct ties to temporary visual properties. By following established do’s and don’ts regarding sizes, states, and groups, designers can build auto-layout hierarchies that developers can easily translate into semantic code.
Official Statements and Deep Dives: Enterprise Taxonomy Case Studies
Scaling a naming system across a massive enterprise with multiple sub-brands requires institutional rigor. Major organizations have open-sourced their internal naming blueprints to guide the broader community.
Intuit’s Multi-Product Design Token Taxonomy
Intuit—the parent company behind powerhouse financial and productivity software such as Mailchimp, QuickBooks, TurboTax, and Mint—faced a formidable challenge: how to build a flexible design token taxonomy that functions seamlessly across distinct, disparate product ecosystems.
In a comprehensive case study, designer Nate Baldwin detailed the creation of Intuit’s scalable token taxonomy. The old taxonomy suffered from being overly tied to specific brand themes, causing bottlenecks when introducing new products or refreshing existing interfaces. Intuit’s solution was to decouple raw primitive values from semantic aliases and component-specific tokens. This foundational taxonomy allowed teams to inherit global styles while retaining localized product flexibility, offering an invaluable masterclass for any organization scaling a multi-product design system.
Vodafone UK’s Variables Taxonomy Map
Similarly, the Vodafone UK Design System team published their Variables Taxonomy Map on the Figma Community. This sophisticated framework breaks down the anatomy and categorization of design tokens into an orchestrated hierarchy of collections.
Building upon Nathan Curtis’s foundational work on token naming conventions, Vodafone’s map illustrates four distinct collections necessary to support a complex, multi-brand ecosystem:
- Brand/Primitives: Raw values (e.g., color hex codes, root spacing metrics).
- Semantics: Purpose-driven tokens (e.g.,
color-background-interactive-hover). - Components: Component-specific bindings.
- Pages/Context: Contextual overrides based on specific page views or themes.
This rigorous mapping enables any team member to instantly understand where a token is utilized and what it represents simply by reading its name. For teams seeking a plug-and-play approach, Romina Kavcic’s Free Design Token Naming Guide + Builder and Design Token Names Inventory Spreadsheet offer interactive structures to manage tokens across components, categories, and states without losing track.
Industry Reference: UI Components & Feature Naming
When struggling to name a UI component, reinventing the wheel is a waste of time. Looking at how established design systems name common UI patterns is the fastest route to clarity.
The Component Gallery
Iain Bean conducted extensive industry research to create The Component Gallery, an exhaustive catalog compiling interface components from real-world design systems. The platform includes rich examples and definitions for over 50 UI components—ranging from accordions and dialogs to visually hidden elements—while meticulously documenting the alternative names these components go by across different tech stacks and design teams.
For a rapid visual reference, Name That UI serves as an indispensable visual dictionary of common UI components, aligning design intent with engineering nomenclature.
Naming New Features for High Adoption
Naming is not merely an internal engineering concern; it directly impacts business metrics. Features frequently suffer from low user adoption due to poor discoverability and confusing nomenclature. As Erin Gannon outlines in her practical guide, What Do We Call This Thing?, feature adoption requires a delicate sequence: the user must first discover the feature, understand its utility, try it, learn it, and eventually integrate it into their existing workflow.
To achieve this, Gannon advises that feature names should:
- Be driven by real user needs and pain points rather than internal corporate jargon.
- Signal the core value or outcome (the "job-to-be-done").
- Tap directly into the user’s own language.
By conducting user interviews and asking customers to explain a capability in their own everyday phrasing, product teams can bridge the gap between developer-speak and user-centric clarity.
Future Outlook: The Horizon of Semantic Automation
As the digital product design industry matures into an era defined by AI-assisted coding, automated design token transformers (such as Style Dictionary), and multi-platform design-to-code pipelines, the importance of pristine nomenclature will only accelerate.
Artificial intelligence models rely heavily on semantic context. When codebases and design systems feature consistent, highly structured, and human-readable names (e.g., following rigorous taxonomy maps), AI coding assistants can generate more accurate components, refactor styles with surgical precision, and maintain design system integrity at scale. Conversely, messy, idiosyncratic naming will poison AI context windows, leading to hallucinated components and broken layouts.
Furthermore, as companies increasingly expand into multi-modal experiences—spanning web, mobile, spatial computing (AR/VR), and conversational interfaces—the need for a unified semantic abstraction layer (design tokens) will become non-negotiable. Organizations that invest time today in codifying their naming strategies, adopting shared component galleries, and auditing their token taxonomies will future-proof their product engineering workflows for the decades ahead.
Wrapping Up: Building a Unified Vocabulary
The ideal name is, ultimately, the one that is universally understood and actively utilized by both the product team and the end-users. Countless hours of engineering and design time are wasted every year because cross-functional partners speak in different dialects: the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect.
If your team is experiencing friction, low feature adoption, or persistent styling bugs, look closely at your naming conventions. Establish a backlog specifically dedicated to resolving naming conflicts and technical debt. By treating nomenclature as a first-class citizen of your product development lifecycle, you can eliminate ambiguity, reduce cognitive overhead, and empower teams to collaborate seamlessly toward building a more accessible, scalable, and coherent digital web.