Executive Overview
In the realm of digital product creation, industry veterans often repeat a foundational axiom: "There are only two hard things in Computer Science: cache invalidation and naming things." While attributed humorously to Phil Karlton, this sentiment strikes at the very heart of daily friction in product design and software engineering. The language we choose does more than merely label an artifact; it actively shapes our cognitive models, influences interpersonal dialogue, and dictates how engineering systems scale.
When teams fail to establish robust naming conventions, widespread organizational confusion inevitably follows. Discrepancies arise over how to classify colors, icons, user interface (UI) components, and core product features. Consequently, designers and developers continually stumble when attempting to name design tokens, HTML classes, architecture variables, and functional features.
The core dilemma of nomenclature often swings wildly between two undesirable extremes. On one end, names can be too generic—rendered so abstractly that deciphering their precise utility becomes an exercise in guesswork. On the other end, names can be too specific, shackling the component or token to a single context and leaving zero room for flexibility, refactoring, or reuse.
To overcome this persistent design debt, modern digital creators must master structured, scalable, and empathetic naming conventions. This comprehensive guide explores the multi-faceted landscape of naming conventions, offering practical resources, expert methodologies, and industry-tested frameworks for UI components, design tokens, color systems, and feature rollouts.
Detailed Chronology: The Evolution of Naming Frameworks in Digital Design
The journey toward systematic naming has evolved alongside the maturation of digital design systems. In the early days of the web, naming was largely ad-hoc. Developers relied on idiosyncratic shortcuts or shorthand identifiers (such as .red-box or .sidebar2), while designers grouped artboards with designations like Rectangle copy 4.
As applications grew more complex and multi-platform design systems emerged, this wild-west approach proved disastrously unsustainable.
- The Era of Primitive Selectors (Late 1990s–2000s): Early stylesheets relied heavily on structural or visual naming conventions. Developers described what something looked like rather than what it was (e.g.,
.blue-textor.float-left). When brand redesigns occurred, these style sheets required massive, error-prone overhauls. - The Rise of Methodology and Modularity (2010s): Recognizing the fragility of visual naming, methodologies like BEM (Block, Element, Modifier) entered the mainstream. BEM introduced strict hierarchical rules for CSS classes, providing a shared mental model for engineering teams. Simultaneously, digital design transitioned from static mockups to symbol-based libraries in tools like Sketch.
- The Design Token Revolution (Present Day): With the advent of multi-brand, multi-themed, and cross-platform applications (spanning web, iOS, Android, and desktop clients), traditional naming broke down entirely. Enter Design Tokens—agnostic, centralized entities storing design decisions. Systems like Intuit’s token taxonomy and Vodafone’s Variables Taxonomy Map transformed naming from a localized styling task into an enterprise-wide architectural challenge.
Today, naming is recognized not as an afterthought, but as a critical infrastructure layer that bridges the communication gaps between product managers, UX designers, accessibility specialists, and software engineers.
Supporting Context & Metrics: Unifying the Multi-Disciplinary Dialect
A primary driver of friction in cross-functional product teams is the existence of departmental dialects. Designers speak in visual metaphors and user flows; developers operate in component lifecycles, states, and variable scopes; product managers focus on user stories, metrics, and feature adoption; and users speak in plain, utilitarian language.
When these groups attempt to collaborate without a unified vocabulary, communication fractures. Teams spend countless hours talking about the exact same object while using entirely different terminology. This linguistic fragmentation directly impacts code maintainability and feature discoverability.
The Cost of Poor Discoverability
Feature adoption metrics often plummet not because a feature lacks utility, but because of poor discoverability rooted in confusing nomenclature. User adoption follows a precise, multi-stage cognitive pipeline:
- Discovery: The user must first locate the feature within the interface.
- Comprehension: The feature’s name and presentation must instantly convey its purpose.
- Trial: The user must be compelled to interact with it.
- Integration: The feature must successfully fold into the user’s existing mental workflows.
If a feature is given an internal, corporate-jargon name rather than one anchored in the user’s vocabulary, the pipeline stalls at the comprehension phase, resulting in dismal engagement metrics.
Methodological Frameworks: How to Name Everything Effectively
1. Naming UI Components and General Code Elements
When struggling with code identifiers, HTML classes, or JavaScript functions, resources like Paul Robert Lloyd’s Classnames offer invaluable inspiration. Moving beyond standard technical vocabulary, Classnames provides thematically grouped lists of words categorized by behavior, likeness, order, and association. It introduces terms drawn from nature, art, theater, music, architecture, fashion, and publishing—helping teams think outside the box without sacrificing semantic clarity.
Similarly, when mapping out real-world interface components, Iain Bean’s Component Gallery aggregates patterns from dozens of production-grade design systems. Covering over 50 UI components—from accordions to visually hidden utilities—the gallery documents the myriad alternative names these components go by in the wild. For a quick visual dictionary, tools like Name That UI provide immediate, unambiguous reference points.
2. Crafting Scalable Color Palettes
Naming colors has historically been plagued by subjective adjectives (light-ish blue, darker grey). To establish scalable palettes, modern systems rely on programmatic or categorical identification. David Aerne’s color-names repository serves as a massive open-source marvel, housing over 30,000 unique color names sourced from community contributions and legacy references. Augmented by tools like Color Parrot, developers and designers can reliably tag exact hex codes with memorable, consistent identifiers.
3. Structuring Layers and Groups in Design Files
In design production tools (such as Figma or Sketch), unorganized layers sabotage collaboration. Javier Cuello’s compilation of naming best practices dictates that an effective design layer name must possess a logical structure: it must be concise, deeply meaningful, universally understood within the team, and entirely divorced from temporary visual properties. Cuello outlines comprehensive do’s and don’ts for sizing, grouping, and nesting elements to ensure files remain clean and scalable as projects grow.
4. Architecting Design Token Taxonomies
Design tokens form the atomic building blocks of modern cross-platform design systems. Building a flexible taxonomy that accommodates multi-brand ecosystems requires rigorous architectural forethought.
- The Intuit Case Study: Faced with supporting diverse brands like Mailchimp, QuickBooks, TurboTax, and Mint, Intuit’s design system team engineered a flexible token taxonomy capable of transcending individual brand themes. Their approach decoupled raw values from semantic applications, allowing a single underlying architecture to power vastly different visual expressions.
- Vodafone UK’s Variables Taxonomy Map: Taking inspiration from Nathan Curtis’s seminal work on design tokens, the Vodafone UK Design System team released an advanced Figma Variables Taxonomy Map. This framework meticulously breaks down the anatomy of a design token across four distinct collections—moving systematically from brand primitives and global variables to semantic roles and page-specific implementations. This ensures that any team member can instantly deduce a token’s origin, scope, and usage context simply by reading its name.
- Romina Kavcic’s Token Builder: For teams seeking interactive guidance, Romina Kavcic’s Design Token Naming Guide and Inventory offers an interactive tool and spreadsheet structure. It provides a clean, four-level hierarchy that grants a bird’s-eye view of all system tokens, enabling seamless filtering and scaling across themes and modes.
5. Naming Products and Core Features
When naming user-facing features or entirely new product lines, internal cleverness should always take a back seat to user clarity. As UX writer Erin Gannon outlines in her practical guide "What Do We Call This Thing?", feature names must be driven by user needs and structural outcomes rather than internal engineering milestones.
The golden rule of feature nomenclature is to tap directly into the user’s natural language. Product teams should conduct user interviews, ask participants to describe core tasks in their own colloquial terms, and harvest those exact phrases for feature titles. Furthermore, platforms like Onym provide open-source repositories, brainstorming methodologies, and vetting tools to help product teams navigate the complex waters of brand and service naming.
Future Outlook
As the digital landscape marches toward hyper-personalized, multi-modal, and AI-driven interfaces, the importance of pristine nomenclature will only intensify. Artificial intelligence models, automated design-to-code pipelines, and multi-platform token parsers rely entirely on strict, unambiguous naming structures to function correctly. A broken taxonomy in a design token file can cascade into broken builds, inaccessible user interfaces, and fractured brand experiences across web, mobile, and ambient computing environments.
Looking ahead, organizations that treat naming as a first-class engineering and design discipline—rather than an afterthought—will outpace their competitors. By fostering shared vocabularies that bridge the gap between user intent, design architecture, and developer implementation, teams can finally eliminate the friction of miscommunication and build systems that scale gracefully into the future.