Naming is universally acknowledged as one of the hardest problems in software development and design. The language teams use does more than simply label things; it actively shapes how individuals think about problems and dictates the conversations they have around them. This fundamental linguistic disconnect often generates profound confusion surrounding colors, icons, user interface components, and features. Consequently, professionals frequently find themselves struggling to establish coherent names for design tokens, HTML classes, and variables.
Often, the names chosen during the development lifecycle fall into one of two detrimental extremes. They are either too generic, making it nearly impossible to understand what is actually meant, or they are too specific, leaving little room for flexibility, scaling, and reuse. Navigating this delicate balance requires a closer look at established resources, modern naming conventions, and structural frameworks used by leading organizations across the digital product landscape.

How To Name Things
For developers and designers seeking fresh inspiration for naming HTML classes, CSS properties, or JavaScript functions, specialized resources offer a way out of traditional cognitive loops. Tools like Classnames, curated by Paul Robert Lloyd, provide a wonderful repository jam-packed with ideas designed to get practitioners thinking outside the box.
The platform supplies thematically grouped lists of words that are ideal for coding contexts. Users can find terms describing different kinds of behavior, likeness between elements, order, grouping, and association. Furthermore, it features themed collections of words that might not instantly come to mind when writing code, drawing from domains such as nature, art, theater, music, architecture, fashion, and publishing. By broadening the vocabulary available to digital creators, these resources help prevent the repetitive use of mundane identifiers.

How To Name Colors
Choosing the right name for a specific color presents another perennial challenge for design system architects. Fortunately, David Aerne maintains a massive repository of color names, which currently boasts over thirty thousand unique color identifiers sourced from diverse references and thousands of individual user contributions.
This comprehensive repository includes color pickers and name search functionality alongside alternative selection tools. Such projects serve as an invaluable, nearby reference for teams striving to maintain consistency across expansive digital ecosystems where color palettes frequently scale into the hundreds.

How To Name Layers and Groups
Establishing a strong foundation for file organization begins at the layer level. Javier Cuello has summarized a definitive set of naming best practices designed to help teams organize layers, groups, and components in a manner that remains both consistent and scalable over time.
As Cuello highlights, an effective name possesses a logical structure, remains concise yet meaningful, is universally understood across multidisciplinary teams, and avoids reliance on transient visual properties. By outlining clear dos and don’ts, these guidelines address the minute details practitioners must weigh when defining scales, colors, groups, layers, and components within modern design software.

How To Name Design Tokens
Building a flexible design token taxonomy capable of functioning seamlessly across a diverse family of products represents a major architectural undertaking. This exact challenge was confronted by the team at Intuit, the parent company behind household names like Mailchimp, QuickBooks, TurboTax, and Mint. To solve it, the organization developed a flexible token system extending far beyond single-brand themes to act as a foundational infrastructure for a wide array of distinct applications.
Nate Baldwin documented this initiative in a detailed case study, sharing valuable insights into the creation of Intuit’s design token taxonomy. The narrative explores the pain points inherent in their legacy systems, outlines the explicit criteria established for the new architecture, and details the implementation process. These learnings provide actionable takeaways for engineering and design teams looking to construct robust, scalable token taxonomies of their own.

Frequent Names For UI Components
When struggling with nomenclature, examining the conventions established by existing design systems provides a pragmatic starting point. To spare practitioners from getting lost down the design system rabbit hole, Iain Bean conducted the necessary research to build the Component Gallery.
This expansive collection features real-world examples for more than fifty distinct UI components—ranging from basic accordions to visually hidden utility elements—while also cataloging alternative names frequently used across the industry. It stands out as a valuable reference that extends well beyond mere naming conventions. Similar initiatives, such as Name That UI, offer visual dictionaries of common interface elements to further assist teams in standardizing their component libraries.

How To Name New Features
New features frequently suffer from low user adoption driven primarily by poor discoverability. Achieving true feature adoption requires a deliberate trajectory: first, the feature must be discovered, then understood, subsequently tried and learned, and finally integrated into the user’s existing workflow. Erin Gannon addressed these dynamics in a practical guide focused on ensuring every stage of this adoption cycle succeeds.
According to these guidelines, successful feature names are driven directly by genuine user needs and underlying problems. They should explicitly signal the value or outcome of a feature—focusing squarely on the job to be done—while tapping directly into the vocabulary of the users themselves. Asking individuals to describe a feature using their own words and subsequently adopting that language helps bridge the gap between product creators and consumers.

How To Name Variables and Taxonomy Maps
An exemplary model of complex naming architecture comes from the Vodafone UK Design System team. Their Variables Taxonomy Map breaks down the anatomy and categorization of design tokens into a meticulously organized system of collections within Figma.
The mapping illustrates the four core collections required to support the system alongside the explicit connections linking tokens together, bridging the gap from foundational brand variables and primitives through to semantics and page-level implementations. Building upon Nathan Curtis’s foundational work on design token naming, this structure ensures that team members can immediately discern where a token is utilized and what it represents simply by reading its identifier. Additional frameworks, such as Romina Kavcic’s Design Token Naming Guide and accompanying spreadsheet inventory, offer interactive builders and four-level hierarchical structures to help teams maintain a bird’s-eye view of their tokens without losing track during expansion.

Naming Products and Services
Finding the right moniker for a new product or service involves an entirely different tier of strategic exploration. Open-source repositories like Onym organize a wide array of tools and resources tailored for brainstorming, vetting, running naming sprints, exploring etymologies, and reviewing cautionary tales or specialized naming agencies. These resources encourage fresh ways of thinking when organizations embark on the critical journey of brand and product naming.
Wrapping Up
The ideal name is ultimately the one that is universally understood and actively utilized by both the internal product team and the end users. Substantial amounts of time are frequently lost when designers, developers, product managers, and users speak about the exact same underlying concept using entirely different dialects. This linguistic fragmentation is a primary driver of operational frustration and user confusion.

When digital products experience low adoption rates, the root cause may simply trace back to confusing terminology. Identifying and resolving potential naming conflicts by maintaining an active backlog of linguistic improvements helps minimize friction and fosters better cross-functional collaboration across modern organizations.

