Executive Overview
In the realm of digital product development, an old and pervasive adage holds steadfast: “There are only two hard things in Computer Science: cache invalidation and naming things.” Attributed originally to Martin Fowler, this sentiment strikes a chord with every developer, designer, and product manager who has ever stared blankly at a flashing cursor, desperately trying to synthesize a complex architectural concept, visual state, or abstract data flow into a concise, meaningful string of text.
Language is not merely a tool for communication; it is the fundamental framework through which we conceptualize our work. The words we choose shape our mental models, dictate the nature of our cross-functional team discussions, and ultimately manifest in the user interfaces we build. When design and engineering teams operate in disconnected silos—using different dialects to describe the exact same artifact—friction, miscommunication, and user confusion inevitably follow.
This comprehensive guide explores the multifaceted challenges of naming across the digital product lifecycle. From HTML classes and design tokens to UI component libraries, color systems, and user-facing feature sets, we examine the practical methodologies, community-driven taxonomies, and expert resources available to help modern digital teams establish a unified, scalable vocabulary.
Detailed Chronology: The Evolution of Naming Best Practices
The maturity of the digital design industry over the past decade has brought naming conventions out of the realm of arbitrary developer preference and into the spotlight of enterprise design systems architecture.
Phase One: The Wild West of Early Web Development (Late 1990s – Late 2000s)
In the early days of the web, naming was largely an ad-hoc affair. Developers relied on idiosyncratic abbreviations (fl-l, nav_bar2, red-box) or visually descriptive tags that tied code directly to presentation (big-blue-text). As stylesheets grew and applications scaled, this lack of structure led to brittle codebases, where changing the visual presentation required rewriting entire swaths of markup.
Phase Two: The Rise of Methodologies (2010s)
Recognizing the unsustainable nature of unstructured code, the industry began rallying around structured naming methodologies. Frameworks like BEM (Block, Element, Modifier), OOCSS (Object-Oriented CSS), and SMACSS (Scalable and Modular Architecture for CSS) introduced strict syntactic rules. While these methodologies successfully reduced specificity wars and improved modularity, they also introduced long, cumbersome class names and sparked endless debates over structural purity.
Phase Three: Design Systems and Tokenization (Late 2010s – Present)
With the advent of advanced design tools like Figma and programmatic token pipelines, the challenge of naming expanded beyond HTML and CSS into the design file itself. Design tokens—variables that store design decisions such as colors, typography, and spacing—demanded multi-tiered taxonomies. Enterprises quickly realized that a token named $blue-500 was useless when rebranding from blue to green, shifting the industry toward semantic and functional naming conventions (e.g., --color-action-primary-default). Today, naming is treated as a core architectural discipline, directly tied to enterprise scalability, accessibility, and multi-brand support.
Supporting Context & Metrics: Why Naming Matters
The cost of poor naming is rarely quantified on a balance sheet, but its impacts bleed into every facet of team velocity and product adoption.
The Dialect Divide
In a typical product organization, at least four distinct "dialects" coexist:
- The Designer’s Dialect: Focuses on visual composition, layout constraints, and component variants (e.g., Variant 3: Hug Contents).
- The Developer’s Dialect: Focuses on DOM structure, state management, and semantic HTML (e.g.,
ul.nav-list > li.nav-item). - The Product Manager’s Dialect: Focuses on business metrics, user stories, and feature flags (e.g., Onboarding_Modal_v2_Q3).
- The User’s Dialect: Focuses on mental models, jobs-to-be-done, and intuitive workflows (e.g., "Where do I find my receipts?").
When these dialects fail to intersect, teams waste countless hours translating concepts back and forth. Research into design system governance consistently highlights that onboarding friction for new engineers and designers is directly correlated with the intuitiveness of the system’s naming taxonomy. If a component’s name requires tribal knowledge to understand, its adoption plummets.
Granularity: The Goldilocks Dilemma
Choosing the right name requires navigating two dangerous extremes:
- Too Generic: Names like
.box,.item, or--color-neutralstrip away context, forcing developers to inspect the source code just to understand what a utility does. - Too Specific: Names like
.sidebar-red-banner-buttonlock code and design into a rigid corner, destroying reusability the moment a product requirement shifts slightly.
The sweet spot lies in naming things based on what they represent and how they behave, rather than how they look at a single point in time.
Practical Taxonomies and Expert Resources
To combat the cognitive load of naming, the design and engineering community has produced an array of open-source tools, dictionaries, and architectural guidelines.
1. General Code and Class Naming: Thinking Outside the Box
When struggling to find inspiration for HTML classes, CSS properties, or JavaScript functions, Classnames (developed by Paul Robert Lloyd) serves as an invaluable reference. The platform offers thematically grouped lists of words categorized by behavior, likeness, order, and association. Crucially, it encourages engineers to look beyond standard technical jargon, drawing inspiration from architecture, fashion, publishing, nature, and the arts to create memorable and semantically rich identifiers.
2. Color Systems: Navigating the Palette
Color naming has traditionally relied on generic hex codes or subjective descriptions (is it cyan, teal, or turquoise?). To bring order to chaos, David Aerne’s Color Names repository maintains a staggering database of over 30,000 unique color names sourced from user contributions and historical references. Paired with interactive pickers like Color Parrot, teams can establish consistent, human-readable semantic names for their color tokens rather than relying on arbitrary numerical scales alone.
3. Layers, Groups, and Components in Design Tools
In design software like Figma, disorganized layers can turn a handoff file into an impenetrable maze. Javier Cuello’s design guidelines on naming practices advocate for a logical, concise structure that is universally understood and entirely divorced from visual properties. A good layer name should immediately communicate its structural role within a component tree, ensuring seamless collaboration between designers and design technologists.
4. Design Token Taxonomies: The Enterprise Standard
Scaling design tokens across multi-brand, multi-product ecosystems requires rigorous architectural planning.
- Intuit’s Token Taxonomy: The engineering team behind Mailchimp, QuickBooks, and TurboTax documented their journey toward a flexible token system capable of supporting diverse brand themes under a single foundational umbrella.
- Vodafone UK’s Variables Taxonomy Map: Available as a community Figma resource, Vodafone’s map illustrates the exact anatomy of a design token, breaking down collections from brand primitives to page-level semantics. Building upon Nathan Curtis’s foundational work on token naming, these models ensure that any team member can trace a token’s lineage and exact usage context straight from its identifier.
- Romina Kavcic’s Design Token Guide: For teams looking to build their own systems from scratch, Kavcic’s interactive builder and accompanying inventory spreadsheet provide a bird’s-eye view across four structural levels, allowing seamless filtering across themes and modes.
5. UI Component Standardization
Before reinventing the wheel—or inventing a brand-new name for a common interface pattern—designers and developers can consult Iain Bean’s Component Gallery. This repository aggregates real-world examples and alternative nomenclature for over 50 UI components (ranging from accordions to visually hidden elements), bridging the gap between disparate design systems. This can be paired with visual dictionaries like Name That UI for rapid identification.
6. Feature Naming and User Discoverability
Naming internal code is one challenge; naming user-facing features is another entirely. As Erin Gannon notes in her practical guide on feature discovery, low feature adoption is frequently a symptom of poor naming rather than poor utility. Features must be named using the user’s own language, reflecting outcomes and jobs-to-be-done rather than internal engineering architecture. If users cannot articulate what a feature does using its name, the discoverability pipeline has failed.
7. Product and Service Nomenclature
For broader branding initiatives, repositories like Onym offer open-source resources, brainstorming methodologies, vetting frameworks, and etymological guides to help teams navigate the treacherous waters of product naming.
Future Outlook: The Next Frontier in Semantic Design Systems
As the software industry continues to mature, the intersection of automated tooling, artificial intelligence, and design systems points toward a more synchronized future.
Automated Token Linter and Semantic Checking
We are rapidly approaching an era where linters will do more than catch syntax errors; they will evaluate semantic consistency. Future development environments will automatically flag when a developer attempts to use a primitive token where a semantic token is required, or when a component variant deviates from established enterprise taxonomies.
AI-Assisted Vocabulary Harmonization
Large Language Models (LLMs) trained on comprehensive design system repositories will increasingly serve as real-time arbiters for cross-functional teams. When a product manager proposes a new feature name, an integrated AI assistant can instantly cross-reference codebase variables, design system tokens, and user research lexicons to highlight potential naming conflicts, semantic ambiguities, or accessibility concerns before a single line of code is written.
Closing Thoughts
Ultimately, the right name is simply the one that is universally understood and actively utilized by both the product team and the end user. By treating naming as a deliberate architectural discipline rather than an afterthought, organizations can dramatically reduce friction, eliminate the cognitive overhead of translating between internal dialects, and build digital products that feel cohesive, intuitive, and human.