In the digital product ecosystem, few challenges are as universally acknowledged yet chronically under-resourced as naming conventions. "Naming is hard"—a cliché whispered in nearly every code review, design critique, and product strategy meeting—belies a profound psychological and operational friction point. The language we select does more than merely label an artifact; it actively shapes cognitive models, dictates cross-functional dialogue, and frames architectural scalability.
When organizations struggle to pin down consistent terminology for colors, icons, user interface (UI) components, and new features, the friction ripples outward. Teams find themselves speaking in fragmented dialects: designers rely on visual or layout-centric descriptions, developers default to semantic or programmatic shorthand, product managers lean into business logic and metrics, and users bring their own intuitive, task-oriented vocabulary. This Tower of Babel phenomenon breeds persistent confusion, slows feature adoption, compromises accessibility, and squanders invaluable engineering and design hours.
This comprehensive guide investigates the multifaceted art and science of nomenclature in modern web development and product design. Drawing upon recent industry resources, real-world case studies from tech giants like Intuit and Vodafone, and pioneering open-source tooling, we examine how to establish a unified lexicon. From crafting resilient design token taxonomies and structuring design system layers to naming intuitive UI components and marketable features, this article provides a professional blueprint for standardizing digital language.
Detailed Chronology: The Evolution of Naming Best Practices
The trajectory of how the tech industry approaches naming has evolved hand-in-hand with the maturation of design systems, CSS architectures, and multi-platform component libraries.
The Wild West Era of Unstructured Code (Pre-2010s)
In the early days of modern web design, naming was largely an ad-hoc, localized exercise. Developers wrote CSS classes based on immediate visual appearance (e.g., .blue-button, .text-large, .float-left). As applications scaled, this tightly coupled approach collapsed under its own weight. A simple brand palette update required scouring thousands of lines of code to replace .blue-button with .red-button, proving that naming things after their visual properties was a recipe for technical debt.
The Rise of Methodologies and Scalable Taxonomies (2010–2018)
Recognizing the unsustainable nature of visual naming, the industry pivoted toward structured methodologies. Frameworks like BEM (Block, Element, Modifier), SMACSS, and OOCSS introduced structural predictability to HTML and CSS. Simultaneously, design tools began adopting layer-naming conventions. However, the nomenclature gap between design and development remained vast: designers named layers based on visual hierarchy in canvas files, while developers translated those layers into completely distinct code architectures.
The Design System Revolution and Unified Taxonomies (2018–Present)
The current era is defined by the convergence of design systems, design tokens, and multi-brand scalability. Organizations no longer build static websites; they maintain dynamic, tokenized design systems that must serve multiple brands, themes, and platforms (web, iOS, Android, and desktop). Tools like Figma, token transformers, and cross-functional design token taxonomies—pioneered by design systems leaders at companies like Intuit and Vodafone—have transformed naming from an afterthought into a foundational engineering discipline. Today, naming is understood as an architectural layer just as critical as component state management or API design.
Supporting Context & Metrics: The Cost of Ambiguity
Why does poor naming command such urgent industry attention? The repercussions of ambiguous nomenclature manifest clearly across several operational dimensions:
Cognitive Overhead and Development Velocity: When developers and designers must decipher what a variable like padding-alt-2 or a component named BoxContainer actually represents, velocity plummets. Studies in software maintenance consistently show that developers spend upward of 50% of their time reading and understanding existing code—a process severely impeded by opaque naming.
Feature Discovery and Adoption Deficits: As documented by product strategists like Erin Gannon, new feature adoption often falters not because the underlying utility is flawed, but due to poor discoverability rooted in internal, jargon-heavy naming. If a feature is named after an internal database schema or a corporate acronym rather than the user’s "job-to-be-done," users simply overlook it.
Cross-Disciplinary Misalignment: A 2023 industry survey on design system health highlighted that over 65% of teams experience recurring friction caused by a lack of shared vocabulary between product management, design, and engineering.
To combat these challenges, industry practitioners have curated a robust ecosystem of specialized tools, open-source directories, and conceptual frameworks.
1. General Naming Inspiration: Thinking Outside the Box
When struggling with HTML classes, CSS properties, or JavaScript functions, traditional vocabulary can quickly feel exhausted. Paul Robert Lloyd’s Classnames resource provides a brilliant antidote to naming fatigue. Rather than recycling generic terms, Classnames offers thematically grouped lists of words categorized by behavior, likeness, order, grouping, and association. Crucially, it introduces unexpected thematic collections drawn from nature, art, theater, music, architecture, fashion, and publishing—encouraging engineers and designers to construct more expressive and contextually rich identifiers.
2. Standardizing Color Nomenclature
Naming colors has historically been a subjective minefield where one person’s "teal" is another’s "cyan." David Aerne’s Color Names repository provides a massive, community-driven solution featuring over 30,000 unique color names sourced from diverse references and thousands of user contributions. Paired with companion tools like Color Parrot, teams can easily query, categorize, and assign intuitive, memorable names to brand and functional palettes, eliminating the ambiguity of raw hex codes in design tokens.
3. Layer and Group Structure Best Practices
In design tools like Figma, messy layers destroy scalability. Javier Cuello’s comprehensive guide on Design Best Practices for Naming establishes that an effective layer, group, or component name must possess a logical structure, remain concise, carry clear semantic meaning, be universally understood across the team, and strictly avoid direct references to volatile visual properties. Cuello outlines rigorous do’s and don’ts that teach teams how to structure scales, states, and component hierarchies cleanly.
Advanced Architecture: Design Tokens and Multi-Brand Taxonomies
As digital products expand across multiple brands and themes, standardizing design tokens becomes paramount. Two monumental case studies highlight how enterprise design systems solve this complexity.
Intuit’s Multi-Product Token Taxonomy
Managing iconic products like Mailchimp, QuickBooks, TurboTax, and Mint under a single parent umbrella requires an extraordinarily resilient design token system. Nate Baldwin’s case study detailing Intuit’s design token taxonomy outlines how the company moved beyond rigid brand themes to build a foundational system capable of serving a diverse ecosystem. The new taxonomy successfully resolved legacy pain points by establishing rigorous criteria for how tokens are categorized, aliased, and consumed across disparate codebases.
Vodafone UK’s Variables Taxonomy Map
Taking multi-brand architecture a step further, the Vodafone UK Design System team published their Variables Taxonomy Map on the Figma Community. Building upon Nathan Curtis’s seminal work on design token naming, Vodafone’s map breaks down the anatomy and categorization of a design token into a well-orchestrated system spanning four distinct collections:
Brand: Core foundational values tied to specific corporate identities.
Primitives: Raw values (e.g., pure color scales, base spacing increments).
Semantics: Context-aware tokens that assign meaning to primitives (e.g., color-background-interactive-default).
Pages/Components: Highly specific tokens tailored to unique interface elements or views.
This structured mapping ensures that any stakeholder can instantly trace where a token is used and what functional role it plays simply by reading its identifier.
For teams looking to operationalize these concepts immediately, Romina Kavcic’s Design Token Naming Guide + Builder offers an interactive tool to configure custom token structures using components, categories, states, and roles. This is complemented by her Design Token Names Inventory spreadsheet, which provides a bird’s-eye view of all tokens through a simple, filterable four-level hierarchy.
Component and Feature Nomenclature: Speaking the User’s Language
Navigating UI Component Libraries
When building or adopting UI libraries, inconsistency in component naming can cause massive friction. If one team calls a collapsible container an "Accordion," another a "Collapsible," and a third a "Expander," codebase maintenance becomes a nightmare.
Iain Bean’s Component Gallery resolves this by cataloging interface components from real-world design systems. Covering more than 50 UI components, the gallery documents not only standard implementations but also the alternative aliases each component goes by across different organizations. For an even quicker visual reference, Name That UI serves as an indispensable visual dictionary of common interface patterns.
Naming Features for Discoverability
Product features frequently suffer from abysmal adoption rates not due to poor utility, but because of weak discoverability and confusing nomenclature. As Erin Gannon outlines in her practical guide “What Do We Call This Thing?”, feature names must be anchored firmly in user needs and problems.
Effective feature names should:
Signal the tangible value or outcome of the feature (the user’s "job-to-be-done").
Tap directly into the user’s native vernacular rather than internal corporate jargon.
Be tested by asking users to describe a capability in their own words, aligning the software’s terminology with the user’s mental model.
Product and Service Naming
For overarching products and services, open-source resources like Onym provide structured repositories of brainstorming tools, vetting methodologies, sprint guides, and etymological resources. These tools help teams navigate the treacherous waters of trademark checks, linguistic analysis, and brand identity alignment.
Official Statements and Industry Insights
Reflecting on the psychological and operational dimensions of nomenclature, industry veteran and web standards advocate Vitaly Friedman emphasizes the core thesis of collaborative taxonomy:
"The right name is the one that is well-understood and actively used by both the product team and the end users. So much time is wasted every single day when multidisciplinary teams speak about the exact same system element but in entirely different dialects—the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect. That fragmentation is what quietly generates chronic friction, confusion, and rework."
Friedman further notes that when software suffers from low user adoption or sluggish internal velocity, the root cause is frequently nothing more complicated than a misaligned or opaque name:
"Pay close attention to naming conflicts and log them in a dedicated backlog to address systematically. Standardizing your nomenclature is one of those high-leverage micro-details that drastically reduces cognitive fatigue and empowers cross-functional teams to build better digital experiences together."
Future Outlook: The Horizon of Semantic Design Systems
As the digital landscape marches toward increased automation, artificial intelligence-assisted coding, and multi-modal interfaces, the importance of pristine nomenclature will only accelerate.
AI-Driven Token Management: Future design systems will increasingly leverage AI agents to parse codebase semantics, automatically flagging naming inconsistencies, orphaned tokens, and WCAG accessibility violations based on standardized naming taxonomies.
Unified Design-Code Synchronicity: The persistent gap between design tool layers (e.g., Figma variables) and production code tokens will narrow further through automated token pipelines, making strict, human-readable naming conventions the universal contract between design and engineering.
Natural Language Interfaces: As conversational UI and voice-driven applications become standard touchpoints, software architecture will require naming conventions that translate smoothly from visual components to spoken natural language commands.
Wrapping Up
Naming is undeniably hard, but it is a challenge that yields exponentially to deliberate strategy, shared glossaries, and community-tested frameworks. By utilizing resources like Classnames, The Component Gallery, Intuit and Vodafone’s token taxonomies, and Erin Gannon’s feature-naming guides, organizations can bridge the chasms between diverse departmental dialects. In doing so, they build not just better software, but a more coherent, accessible, and harmonious digital world.
