In the realm of digital product design and software engineering, a persistent adage echoes through every code repository, design system, and product roadmap: "Naming things is hard." While flippant at first glance, this sentiment encapsulates a profound truth about collaborative creation. The language we choose does more than merely label artifacts; it fundamentally shapes how we conceptualize systems, structures our daily conversations, and dictates the velocity of product development.
From colors and interface icons to complex design tokens, architectural layers, and newly launched features, the lack of a cohesive taxonomy leads to institutional friction. Teams frequently find themselves speaking in fragmented dialects—designers utilizing visual descriptors, developers relying on implementation constraints, product managers prioritizing business logic, and users stumbling over internal jargon. This tower of Babel breeds systemic confusion, resulting in low feature adoption, bloated style sheets, fragmented design systems, and hours squandered in meetings attempting to define what "that one component" is actually called.
This comprehensive guide explores the multifaceted challenge of digital nomenclature. Drawing upon industry-leading practices, community-driven resources, and real-world case studies from global organizations like Intuit and Vodafone UK, we examine how to establish scalable, intuitive, and universally understood naming structures. Whether you are standardizing a multi-brand design token architecture, auditing UI components, or naming a customer-facing product feature, the following frameworks will help align your team’s vocabulary with user realities.
Detailed Chronology: The Evolution of Digital Taxonomy
The maturation of the web and software industries traces a direct line toward increasingly sophisticated systems of organization. Understanding how we arrived at our current methodologies provides critical context for modern naming conventions.
Phase 1: The Wild West of the Early Web (1990s–Early 2000s)
In the nascent days of web development, naming was largely ad-hoc. HTML classes and IDs were descriptive of visual presentation rather than semantic meaning (e.g., <div class="blue-box-right">). Because teams were small and projects were often monolithic, the consequences of poor naming were localized. However, as websites grew into complex web applications, this visual coupling became an insurmountable technical debt. Changing a design from blue to red meant refactoring cascading style sheets across thousands of lines of code simply because the class names had locked styling into identity.
Phase 2: Methodologies and Modularization (2010s)
Recognizing the unsustainable nature of unstructured code, the industry pivoted toward strict naming methodologies. Concepts like BEM (Block, Element, Modifier), OOCSS (Object-Oriented CSS), and SMACSS emerged to bring order to the chaos. These systems forced developers to think hierarchically, categorizing UI elements into distinct relationships. Simultaneously, design tools began adopting layer-naming best practices, though graphic design files and codebases largely remained siloed in separate conceptual universes.
Phase 3: The Design Systems Era and Tokenization (Present)
Today, the convergence of design and engineering has elevated nomenclature from a localized coding task to a cross-functional governance issue. With the rise of design systems—comprehensive repositories housing UI components, guidelines, and variables—organizations now manage multi-brand, multi-platform ecosystems. Design tokens have replaced hard-coded values, bridging the gap between Figma variables and CSS custom properties. Consequently, naming is no longer just about writing clean code; it is about establishing a shared corporate lexicon that can scale across products, brands, and accessibility requirements.
Supporting Context & Metrics: The Anatomy of Effective Nomenclature
To solve the naming crisis, practitioners must first understand the structural criteria that separate ambiguous labels from scalable systems. According to design system experts such as Javier Cuello, an effective name possesses several core characteristics: it maintains a logical structure, remains concise, carries explicit meaning, is universally understood across disciplines, and—crucially—avoids direct ties to ephemeral visual properties.
The Balancing Act: Generic vs. Specific
The primary pitfall in nomenclature is landing on the wrong end of the specificity spectrum:
Too Generic: Names like container, box, or item rob the codebase and design file of context. When everything is an "item," nothing can be easily queried, referenced, or understood without inspecting its parent element.
Too Specific: Names like bright-orange-sidebar-button-v2 leave zero room for flexibility or reuse. If the button’s color changes to navy in the next quarter’s rebrand, the name instantly becomes legacy technical debt.
Finding the sweet middle ground requires leaning into the Job-To-Be-Done (JTBD) framework—naming elements based on their structural role or functional outcome rather than their current graphical manifestation.
Practical Resources and Methodologies by Domain
Navigating the labyrinth of digital naming requires the right tools. Industry practitioners have developed a wealth of open-source guides, repositories, and interactive generators to streamline the process.
1. General Code and HTML Classes: Thinking Outside the Box
When struggling to name HTML classes, CSS properties, or JavaScript functions, standard English vocabulary often falls short. Resources like Classnames (curated by Paul Robert Lloyd) provide thematically grouped lists of words that encourage developers to think beyond traditional technical terminology. The platform offers terms categorized by behavior, likeness, order, and grouping, alongside themed collections drawn from nature, architecture, fashion, theater, and publishing.
2. Color Tokens: Taming the Spectrum
Naming colors is notoriously subjective. Is a hex code #2e8b57 best described as forest-green, sea-green, or something entirely unique? To solve this, David Aerne maintains an expansive repository of color names (Color Names / Color Parrot), which catalogs over 30,000 unique color designations sourced from user contributions and historical references. Complete with color pickers and search APIs, this repository serves as an invaluable anchor for maintaining consistent color palettes across design systems.
3. UI Components: The Design System Standard
When establishing a component library, reinventing the wheel wastes valuable time. Before diving down a proprietary naming rabbit hole, practitioners can consult The Component Gallery (created by Iain Bean), which aggregates real-world examples and naming variations for over 50 core UI components—from accordions to visually hidden elements. For a purely visual approach, Name That UI acts as a comprehensive visual dictionary, ensuring your team calls a modal a modal, and a popover a popover.
4. Design Token Taxonomies: Scaling Across Products
Building a token taxonomy that scales across multiple products and brands is one of architecture’s hardest challenges. A prominent benchmark is the work executed by the team at Intuit—parent company to Mailchimp, QuickBooks, TurboTax, and Mint. As detailed in case studies by Nate Baldwin, Intuit engineered a flexible design token system that transcends individual brand themes to serve a massive portfolio of financial and marketing software.
Similarly, the Vodafone UK Design System team released their comprehensive Variables Taxonomy Map on Figma. This system maps out the anatomy of design tokens across four interconnected collections:
Brand: Core global values tied to corporate identity.
Primitives: Raw, uncontextualized values (e.g., spacing scales, raw hex codes).
Semantics: Contextual tokens that assign meaning to primitives (e.g., color-background-primary).
Pages/Components: Highly specific tokens utilized within localized UI patterns.
For teams looking to operationalize this approach, Romina Kavcic’s Design Token Naming Guide + Builder and associated Design Token Names Inventory spreadsheet offer interactive frameworks to structure components, categories, states, and roles without losing track during enterprise-scale updates.
5. Product Features: Designing for Discoverability
Poor feature adoption is frequently a symptom of poor naming rather than poor utility. When a feature has low discoverability, users cannot find it, understand it, or integrate it into their existing workflows.
As outlined in Erin Gannon’s practical guide on feature naming, effective feature titles must be driven by user research. Instead of internal engineering codenames (e.g., "Project Helios"), features should be named using the user’s own language. By asking target users to describe a solution in their conversational vocabulary, product teams can align feature titles with real-world mental models, dramatically accelerating discoverability and trial rates.
Official Statements and Industry Insights
Reflecting on the psychological and operational weight of nomenclature, design leaders emphasize that naming is fundamentally an act of communication design.
"The language we use shapes the way we think about things, but also the conversation we have about it. When design and engineering teams speak different dialects, the resulting product reflects that internal friction. Standardizing our taxonomy is the single highest-leverage activity a design system team can undertake."
— Industry Design Systems Lead
Furthermore, experts highlight that naming conflicts should never be swept under the rug. Left unaddressed, minor discrepancies in component nomenclature compound over time, culminating in bloated design debt and frustrated cross-functional squads. Establishing a living backlog for naming refactoring is a hallmark of mature, scalable product organizations.
Future Outlook: The Next Frontier of Nomenclature
As artificial intelligence, automated design-to-code pipelines, and multi-modal design tokens continue to evolve, the future of digital naming will likely see increased automation coupled with stricter semantic governance.
We are moving toward an era where AI-driven linting tools will automatically flag semantic drift—detecting when a component name deviates from established enterprise taxonomies or when a color token is being misused outside its defined semantic scope. However, technology can only automate governance; the foundational empathy required to understand user language and cross-disciplinary team dynamics remains a uniquely human responsibility.
By investing time in robust naming structures, maintaining shared inventories, and actively listening to the vocabulary of our users, we transform nomenclature from an administrative chore into a strategic competitive advantage.
Editor’s Note: At Smashing, we love the web. That’s why we publish in-depth articles, books, and run online workshops and events covering everything from accessibility to design systems. If you are interested in exploring our upcoming online training programs—with friendly discounts available for students and large groups of five or more—please feel free to reach out via our contact channels.
