Naming things remains one of the most persistent and vexing challenges in software development and digital design. The language teams choose not only shapes how they think about digital products, but it also dictates the quality and clarity of the conversations surrounding them. This fundamental friction often manifests as widespread confusion over colors, icons, user interface components, and features, ultimately trickling down into struggles when naming design tokens, HTML classes, and variables.
Often, the labels chosen during development fall into two problematic extremes. They can be overly generic, rendering it nearly impossible to understand what is actually meant, or they can be excessively specific, leaving virtually no room for flexibility, scalability, or reuse. Navigating this delicate balance to choose the right nomenclature and identifying which naming conventions work best requires examining a growing ecosystem of community-driven resources, case studies, and frameworks designed to bring order to the chaos.
How To Name Things
For professionals seeking inspiration when naming HTML classes, CSS properties, or JavaScript functions, resources like Paul Robert Lloyd’s "Classnames" offer a repository of ideas designed to provoke unconventional thinking. The platform provides thematically grouped lists of words tailored specifically for coding nomenclature. Users can browse terms that describe various types of behavior, structural likeness, order, grouping, and association.
Beyond standard technical vocabulary, the resource includes themed collections drawn from unexpected domains such as nature, art, theater, music, architecture, fashion, and publishing. These curated word lists help developers and designers break away from repetitive, unimaginative naming patterns, encouraging a richer vocabulary that can better reflect the nuanced relationships within a codebase.
How To Name Colors
Determining the appropriate name for a specific color value has historically led to endless debates among designers and developers. To alleviate this friction, David Aerne maintains an expansive repository of color names known as color-names, which currently houses over thirty thousand unique identifiers sourced from various references and thousands of user contributions.
Supplemented by interactive tools like Color Parrot—which originally gained traction via social media before evolving into a web utility—the repository provides developers with color pickers and name searches. This extensive database serves as an invaluable reference tool to keep nearby, helping teams establish consistent color semantics without resorting to arbitrary hex codes or overly restrictive shade numbers.
How To Name Layers and Groups
Establishing consistency within design files is just as crucial as maintaining clean codebases. Javier Cuello recently synthesized a comprehensive set of naming best practices aimed at helping teams structure their layers, groups, and components in a scalable manner.
According to Cuello’s guidelines, an effective name possesses a logical structure while remaining concise, meaningful, universally understood within the team, and entirely decoupled from transient visual properties. By outlining clear dos and don’ts, these guidelines address the minute details practitioners must weigh when labeling sizes, colors, groups, layers, and components across collaborative design environments.
How To Name Design Tokens
Building a flexible design token taxonomy that operates seamlessly across multiple products and brand themes represents a major hurdle for enterprise organizations. This exact challenge was confronted by the design system team at Intuit, the parent company behind household financial and productivity products such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify their ecosystem, the team engineered a flexible token architecture capable of stretching far beyond a single brand theme to serve as the foundational bedrock for a vast array of distinct products.
In a detailed case study, Nate Baldwin shared critical insights into the creation of Intuit’s design token taxonomy. The documentation outlines the underlying pain points of their legacy taxonomy system, the rigorous criteria established for the new framework, and the step-by-step methodology behind its implementation. These insights offer valuable takeaways for organizations seeking to construct robust, adaptable token taxonomies of their own.
Frequent Names For UI Components
When struggling with nomenclature, examining how other practitioners label comparable interface elements provides an immediate starting point. To spare teams from tumbling down an exhaustive design system rabbit hole, Iain Bean developed the Component Gallery, an archive cataloging interface components sourced from real-world design systems.
The repository compiles concrete examples for more than fifty distinct UI components—ranging from basic accordions to accessibility-focused utility classes like visually hidden elements—while also documenting alternative names associated with each component. This collection functions as a practical reference for cross-functional teams striving to align their internal lexicon with industry standards. Additionally, supplementary visual dictionaries such as "Name That UI" offer further assistance in identifying common interface components at a glance.
How To Name New Features
Low feature adoption is frequently rooted not in a lack of utility, but in poor discoverability and confusing nomenclature. Realizing the value of a newly introduced capability takes time: users must first discover it, understand its purpose, try it out, learn its mechanics, and eventually integrate it into their existing workflows. Erin Gannon addressed these challenges in a practical guide focused on ensuring features are actually discovered, understood, and utilized.
According to these guidelines, successful feature names are driven fundamentally by user needs and underlying problems. They should explicitly signal the value or intended outcome—addressing the user’s "job-to-be-done"—while tapping directly into the language customers already use. By prompting users to explain a feature in their own conversational terms, product teams can avoid internal jargon and adopt terminology that resonates naturally with their audience.
How To Name Variables and Taxonomy Maps
A prime example of advanced naming governance within a complex, multi-brand ecosystem comes from the Vodafone UK Design System team. Their publicly shared Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into an organized system of collections.
Building upon foundational work by design systems expert Nathan Curtis, the Vodafone map illustrates the four distinct collections necessary to support a multi-themed system: brand, primitives, semantics, and pages. This clear lineage maps out the connections between tokens, empowering any team member to discern precisely where a token is utilized and what it represents simply by reading its identifier. For practitioners looking to explore alternative approaches, additional Figma kits and community resources provide further methodological variety.
Similarly, Romina Kavcic developed an interactive tool known as the Design Token Naming Guide alongside a comprehensive Design Token Names Inventory spreadsheet. This framework utilizes a structured four-level hierarchy to provide a bird’s-eye view of an entire token library, allowing teams to seamlessly introduce new rows, themes, and modes while retaining the ability to filter and track assets effectively.
Naming Products and Services
For teams tasked with naming brand-new products or services, open-source repositories like Onym aggregate tools, brainstorming methodologies, vetting frameworks, sprints, and etymological guides. By centralizing resources ranging from foundational literature to cautionary tales and specialized naming agencies, the platform encourages fresh perspectives during the early stages of product development.
Wrapping Up
Ultimately, the most effective name is one that is universally understood and actively utilized by both the internal team and the end users. A significant amount of engineering and design time is routinely lost when multidisciplinary teams discuss identical concepts using divergent dialects—such as the specialized vocabulary of designers, developers, product managers, and customers. This linguistic fragmentation frequently breeds avoidable frustration and operational confusion.
Recognizing that low feature adoption or cross-departmental friction may stem directly from ambiguous naming conventions allows teams to address these roadblocks proactively. Documenting potential naming conflicts in a dedicated backlog is a subtle yet impactful practice that streamlines collaboration and fosters a shared understanding across modern digital organizations.
