Main Facts: The Eternal Dilemma of Nomenclature in Digital Design
In the realm of digital product creation, a universally acknowledged axiom persists: naming things is undeniably hard. Whether developers are attempting to label a nuanced CSS class, designers are wrestling with design token hierarchies, or product teams are scrambling to find a marketable moniker for a newly launched feature, nomenclature serves as the invisible glue holding a project together. The language utilized within a digital ecosystem does more than merely label artifacts; it fundamentally shapes how cross-functional teams conceptualize problems, structure codebases, and converse with users.
When labels fail, friction ensues. Teams frequently find themselves trapped in silos, speaking entirely different "dialects"—the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the end-user’s dialect. This Babel-like confusion leads to massive inefficiencies, redundant code, low feature adoption, and profound user frustration.
Fortunately, a growing movement within the design systems and software engineering communities aims to eradicate this chaos. Practitioners are actively curating resources, establishing rigorous naming conventions, and building open-source repositories to transform naming from an arbitrary guessing game into a structured, scalable science.
Chronology and Evolution: From Ad-Hoc Labeling to Systematic Taxonomies
To understand the current state of UI and design token naming, one must look at how digital architecture has evolved over the past two decades.
The Early Web (Late 1990s – Early 2000s): Naming was largely an ad-hoc, localized affair. Developers used ID and class names based on immediate visual appearance (e.g., .red-box, .big-text) or arbitrary shorthand.
The Rise of Methodologies (2010s): As web applications scaled, the need for scalable CSS architectures birthed methodologies like BEM (Block, Element, Modifier), SMACSS, and OOCSS. These frameworks forced developers to think structurally, separating component styles from layout contexts.
The Design Systems Era (Mid-2010s – Present): With the proliferation of tools like Figma and the integration of design tokens into code repositories, naming expanded beyond HTML classes. It now bridges the gap between static design files and dynamic codebases. Organizations began treating design tokens as APIs, requiring strict taxonomies that could span multiple brands, themes, and platforms.
Today, the frontier of naming is no longer just about keeping stylesheets clean; it is about creating holistic linguistic systems—ranging from color palettes to multi-brand variables and user-facing feature sets.
Supporting Data, Frameworks, and Essential Resources
Navigating the complexities of naming requires stepping outside of habitual patterns. Several pioneering creators and organizations have developed invaluable tools and repositories to assist practitioners in finding the precise language they need.
1. Inspiring Code and Class Names
When struggling to name HTML classes, CSS properties, or JavaScript functions, Classnames (curated by Paul Robert Lloyd) acts as a gateway to thinking outside the box. The platform provides thematically grouped lists of words categorized by behavior, likeness, order, and association. Crucially, it introduces unexpected thematic collections drawn from nature, art, theater, music, architecture, fashion, and publishing—injecting semantic richness into dry codebases.
2. Taming the Color Spectrum
Color nomenclature has historically swung between hex codes (e.g., #FF5733) and hyper-specific design names that mean little outside a single team. To combat this, David Aerne maintains a massive repository of color names via Color Names and Color Parrot. Boasting over 30,355 unique color names sourced from diverse references and thousands of user contributions, this repository—complete with color pickers and search utilities—provides a shared vocabulary for visual elements.
3. Layer and Group Best Practices in Design Tools
In design files (like Figma or Sketch), messy layer panels are productivity killers. Javier Cuello has formalized a set of naming best practices for layers, groups, and components. According to Cuello’s guidelines, an effective name must possess a logical structure:
It must be short and meaningful.
It must be universally understood by the team.
Crucially, it should not relate to visual properties (e.g., avoiding names like "Blue Rectangle" in favor of "User Avatar Container").
4. Enterprise-Scale Design Token Taxonomies
Scaling a design system across massive conglomerates presents unique nomenclature challenges. The team at Intuit—parent company to Mailchimp, QuickBooks, TurboTax, and Mint—faced the monumental task of building a flexible token taxonomy that operates seamlessly across vastly different product ecosystems. Nate Baldwin documented this journey in a comprehensive case study, outlining how Intuit transitioned from legacy naming pain points to a unified token structure.
Similarly, the Vodafone UK Design System team released their Variables Taxonomy Map on Figma. This complex map breaks down design token anatomy across four core collections:
Brand
Primitives
Semantics
Pages
Building upon Nathan Curtis’s foundational work on token naming, Vodafone’s system ensures that any team member can immediately deduce where a token is deployed and what it represents simply by reading its identifier.
5. UI Component Dictionaries
When building out a design system, reinventing the wheel—or the name—is counterproductive. Iain Bean’s Component Gallery aggregates interface components from real-world design systems, providing examples and alternative names for over 50 UI components (ranging from accordions to visually hidden utilities). This is complemented by Name That UI, a visual dictionary designed to bridge the gap between abstract UI patterns and their standardized industry titles.
6. Feature Discovery and User-Centric Naming
Naming internal components is one challenge; naming user-facing features is another entirely. Poor discoverability often masquerades as a lack of feature adoption. As UX writer Erin Gannon outlines in her practical guide, “What Do We Call This Thing?”, feature adoption is a sequential journey: discovery $rightarrow$ understanding $rightarrow$ trial $rightarrow$ learning $rightarrow$ workflow integration.
Gannon emphasizes that feature names must be driven by user needs and problems. They should signal the value or outcome of a feature—the "job-to-be-done"—and, most importantly, tap into the user’s native vocabulary. Asking target users to describe a functionality in their own words is often the fastest route to high discoverability.
7. Product and Service Nomenclature
For teams launching entirely new products or services, open-source repositories like Onym provide structured methodologies, brainstorming frameworks, vetting exercises, and ethical cautionary tales to guide brand naming from conception to execution.
Official Industry Perspectives and Expert Insights
Industry leaders continually emphasize that language is a design material. Vitaly Friedman, co-founder of Smashing Magazine, highlights that organizational friction often stems from linguistic fragmentation:
"So much time is wasted speaking about the very same thing but in different dialects… That’s what often causes frustration and confusion. If you see low adoption rates for a feature or a design system component, it might be merely because of the name."
Design token experts like Romina Kavcic—creator of the Free Design Token Naming Guide + Builder and the Design Token Names Inventory spreadsheet—advocate for structured token taxonomy matrices. By implementing clear hierarchies (encompassing components, categories, states, and roles), teams can maintain bird’s-eye visibility over their design systems, effortlessly accommodating new themes and modes without sacrificing scalability.
Implications for Future Digital Workflows
The meticulous attention currently being paid to naming conventions is not merely an aesthetic or organizational preference; it carries profound structural implications for the future of software development and design operations:
Accelerated Onboarding: When codebases and design systems utilize intuitive, standardized, and semantic naming conventions, new engineers and designers ramp up significantly faster. The cognitive load required to understand what a variable, token, or component does drops precipitously.
Enhanced Design-Developer Collaboration: A unified taxonomy bridges the persistent gap between Figma variables and code tokens. When designers and developers use identical nomenclature, handoffs become seamless, and automated token synchronization pipelines (such as Style Dictionary) function without manual translation errors.
Improved Accessibility and Maintainability: Semantic naming practices—such as avoiding visual descriptors (e.g., .blue-button) in favor of functional ones (e.g., .btn-primary)—ensure that codebases remain resilient against brand refreshes and theme modifications (such as dark mode implementations).
Data-Driven Product Success: By aligning feature names with the mental models and everyday language of actual users, companies can drastically reduce drop-off rates, lower customer support overhead, and maximize return on investment for newly shipped capabilities.
Wrapping Up
Naming is hard, but it is a challenge that yields compounding returns when tackled with intention. By treating nomenclature as an active design discipline—leveraging community resources like Classnames, Color Names, the Component Gallery, and structured token taxonomies—teams can eliminate cross-departmental confusion, foster harmonious collaboration, and build resilient, scalable digital ecosystems that stand the test of time.
By Nana Muazin 
Iffa Jayyana 
Azzam Bilal Chamdy 
Nila Kartika Wati 