Executive Overview
In the realm of digital product development, an old, persistent adage holds true: naming things is hard. Whether architects of the web are wrestling with CSS classes, organizing design tokens, labeling Figma layers, or pitching newly minted software features to cross-functional teams, the vocabulary chosen shapes not only how developers and designers think, but how entire organizations communicate.
When labels fail, friction ensues. Teams frequently find themselves speaking in isolated dialects—designers using visual jargon, developers leaning on technical shorthand, product managers talking in metrics, and users experiencing pure confusion. Poor nomenclature leads to low feature adoption, architectural drift, and countless hours lost in meetings trying to define what "that specific blue button" actually means.
This comprehensive guide aggregates foundational insights, robust frameworks, and invaluable community-driven resources to help teams master the art and science of nomenclature. From picking the right color aliases to architecting multi-brand design token taxonomies, we explore how structured language can streamline workflows, align stakeholders, and ultimately bridge the gap between code and user experience.

Detailed Chronology & The Evolution of Naming Practices
The digital design industry’s approach to nomenclature has evolved significantly over the past decade, shifting away from ad-hoc, siloed naming conventions toward scalable, systemic taxonomies.
Phase 1: The Wild West of Web Development (Pre-2010s)
In the early days of modern web design, naming was largely decentralized. Developers named HTML classes based on immediate visual appearance (e.g., .blue-box, .float-right), while designers kept desktop files littered with names like Rectangle copy 4 or Group 12. This hyper-specific, visual-first approach created maintenance nightmares. When a redesign called for turning .blue-box red, engineers were forced to either leave misleading codebases or execute sweeping, error-prone refactors.
Phase 2: Modular Systems and Methodology (2010–2018)
As web applications grew in complexity, methodologies like BEM (Block, Element, Modifier), SMACSS, and Atomic Design emerged to bring sanity to CSS and component architecture. Naming began to reflect structural relationships rather than transient visual states. Concurrently, UI design tools introduced symbols and components, forcing teams to establish standardized layer-naming conventions to keep design systems organized.

Phase 3: The Design Token Era and Multi-Brand Scaling (2018–Present)
Today, modern design systems—spanning massive conglomerates like Intuit, Vodafone, and beyond—rely on design tokens as the single source of truth connecting design tools to multi-platform codebases. Naming has matured into a sophisticated taxonomy problem. Tokens must now account for multiple brands, themes, platforms, and accessibility modes without breaking down. As a result, the industry has birthed an array of open-source directories, taxonomy maps, and interactive tools designed to democratize and standardize language across disciplines.
Supporting Context, Frameworks, and Practical Resources
Choosing the right name requires balancing two extremes: names that are too generic (leaving users and developers guessing the context) and names that are too specific (leaving no room for flexibility or reuse).
To help practitioners navigate this balancing act, the community has developed a rich ecosystem of reference tools, repositories, and structured methodologies.

1. Expanding Vocabulary for Code: Classnames
When struggling to name HTML classes, CSS properties, or JavaScript functions, looking beyond standard technical vocabulary is often necessary. Created by Paul Robert Lloyd, Classnames is an exceptional resource packed with thematic lists of words designed to inspire out-of-the-box thinking.
Rather than relying on repetitive terms, the site groups words by behavior, likeness, order, grouping, and association, alongside thematic collections drawn from nature, art, theater, music, architecture, fashion, and publishing. It serves as an intellectual palette cleanser for developers stuck in a lexical rut.
2. Standardizing the Spectrum: Color Nomenclature
Naming colors has historically been an exercise in subjectivity—what one designer calls "Slate," another might call "Graphite" or "Steel." David Aerne’s Color Names repository solves this by aggregating a staggering 30,355 unique color names sourced from various references and thousands of user contributions.

Equipped with a built-in color picker and name search (via utilities like Color Parrot), this repository provides an authoritative reference point for teams establishing predictable, shared color tokens across codebases.
3. Layer and Group Hygiene: Javier Cuello’s Best Practices
In design software like Figma or Sketch, messy file organization scales chaos exponentially. Javier Cuello outlines foundational guidelines in his naming best practices handbook, emphasizing that effective layer and group names must be:
- Logically structured
- Concise yet meaningful
- Universally understood within the organization
- Free from direct references to transient visual properties
By following clear do’s and don’ts, design teams can maintain scalable component libraries that developers can easily navigate.

4. Enterprise-Scale Taxonomies: The Intuit and Vodafone Case Studies
Scaling a design system across multiple enterprise products requires rigorous token architecture.
- Intuit’s Taxonomy: Nate Baldwin detailed the creation of Intuit’s flexible design token taxonomy in a widely read case study. By analyzing the pain points of legacy systems, Intuit built a token framework capable of supporting wildly diverse products like Mailchimp, QuickBooks, TurboTax, and Mint under a unified architectural umbrella.
- Vodafone UK’s Variables Taxonomy Map: The Vodafone UK Design System team released a comprehensive Variables Taxonomy Map on Figma Community that builds upon Nathan Curtis’s seminal work on design tokens. It maps out four distinct collections—moving seamlessly from brand primitives to semantics and page-level variables—ensuring that a token’s very name reveals its exact purpose and context.
5. Cross-Referencing UI Components: The Component Gallery
When struggling to name a custom interface element, checking what established design systems call it is the best heuristic. Iain Bean’s Component Gallery indexes real-world design systems across more than 50 UI components (ranging from accordions to visually hidden elements), listing alternative names and contextual implementations. For a purely visual approach, Name That UI functions as an indispensable visual dictionary.
6. Designing for Discoverability: Naming New Features
Low feature adoption is frequently a symptom of poor discoverability and misaligned naming. As Erin Gannon outlines in her practical guide, “What Do We Call This Thing?”, effective feature names must be driven by user needs and jobs-to-be-done.

Rather than using internal corporate jargon or overly clever product marketing names, teams should capture the user’s natural language. Asking real users to explain a feature in their own words ensures that software labels reflect actual user workflows, vastly accelerating trial and adoption.
7. Interactive Token Builders: Romina Kavcic’s Guides
To operationalize design tokens, Romina Kavcic offers the Design Token Naming Guide + Builder, an interactive tool that helps teams configure robust naming structures encompassing components, categories, states, and roles. Complemented by the Design Token Names Inventory spreadsheet, this toolkit gives teams a bird’s-eye view of multi-themed token architectures without losing track of dependencies.
Official Statements and Industry Insights
Industry leaders continually emphasize that nomenclature is not merely a cosmetic choice, but a foundational pillar of software architecture and team ergonomics.

"The language we use shapes the way we think about things, but also the conversation we have about it. That’s why we have so much confusion about colors, icons, UI components, features — and that’s why we struggle to name design tokens, HTML classes, and variables."
— Editorial Consensus from Leading Web Design Communities
Experts note that technical debt often originates not in sloppy code, but in ambiguous communication. When product managers, designers, and engineers operate under different conceptual frameworks, the resulting software reflects those organizational silos. Investing time upfront in defining a shared lexicon eliminates semantic friction and aligns cross-functional velocity.
Future Outlook: The Next Frontier of Naming Systems
As artificial intelligence, automated design-to-code pipelines, and multi-platform ecosystems continue to mature, the precision of our naming conventions will become even more critical.

- AI-Driven Token Generation: AI assistants are increasingly tasked with generating code from design files or writing documentation based on component libraries. Clean, semantically rigorous naming structures act as essential training wheels for AI models, ensuring generated outputs match enterprise standards.
- Automated Governance: Future design system tooling will likely incorporate real-time semantic analysis to flag naming conflicts, orphaned tokens, and non-standard component aliases before they ever reach production.
- Universal Design Glossaries: As design systems scale to accommodate spatial computing, voice interfaces, and ambient computing, the taxonomy of UI components will expand beyond traditional two-dimensional paradigms, requiring entirely new classes of behavioral and spatial descriptors.
Wrapping Up
The right name is, fundamentally, the one that is universally understood and actively used by both the development team and the end user. Countless hours are wasted every day simply because stakeholders speak in conflicting dialects—the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect.
If a feature suffers from low adoption or a design system feels brittle, the root cause may simply be poor nomenclature. By auditing naming conflicts, establishing robust token taxonomies, and adopting community-vetted guidelines, teams can drastically reduce friction, eliminate confusion, and foster a more collaborative, efficient digital ecosystem.
Editor’s Note: A friendly shout-out to all the creators, engineers, and designers who openly share their tools, frameworks, and methodologies with the global community. Your contributions make the web a more accessible, structured, and beautiful place.
