Naming things in design and software development is notoriously difficult. The language teams choose not only shapes how they think about digital products, but it also dictates the clarity and efficiency of their everyday conversations. This fundamental hurdle leads to ongoing confusion regarding colors, icons, user interface components, and core features, while simultaneously complicating the process of establishing design tokens, HTML classes, and code variables.
Often, the labels chosen during the design and development phases suffer from two opposite extremes. They can be overly generic, making it nearly impossible to understand their precise intent or context, or they can be excessively specific, leaving little room for systemic flexibility, scalability, and code reuse. Addressing this persistent industry challenge requires a closer look at how leading design systems, developers, and product teams approach the art and science of naming.
How To Name Things
Finding the right inspiration for naming HTML classes, CSS properties, or JavaScript functions often requires looking beyond standard technical dictionaries. For professionals seeking to break out of routine mental patterns, Classnames—a resource developed by Paul Robert Lloyd—offers a curated collection of ideas designed to provoke unconventional thinking.
The platform provides thematically grouped lists of words tailored for nomenclature tasks. Users can explore terms describing behavior, functional likeness, order, grouping, and association. Furthermore, the resource includes themed collections drawn from disciplines that do not instantly come to mind in a programming context, ranging from nature, art, and theater to music, architecture, fashion, and publishing.
How To Name Colors
Selecting precise and scalable names for specific color palettes presents another recurring challenge for digital creators. To streamline this process, David Aerne maintains an expansive repository of color names known as color-names, which currently houses over 30,000 unique color designations sourced from diverse references and thousands of individual user contributions.
Accompanying tools, such as Color Parrot and associated color pickers hosted on GitHub and CodePen, allow teams to search existing names or assign intuitive identifiers to custom shades. This robust infrastructure serves as an invaluable reference library for developers and designers striving to maintain consistency across multi-brand applications.
How To Name Layers and Groups
Establishing consistency within digital design files is just as critical as maintaining clean codebases. Javier Cuello has synthesized a comprehensive set of naming best practices aimed at helping teams structure layers, groups, and components in a scalable manner.
According to Cuello’s guidelines, an effective name possesses a logical structure, remains concise yet meaningful, is universally understood across cross-functional teams, and avoids reliance on transient visual properties. By analyzing specific do’s and don’ts, these guidelines address the nuanced decisions required when defining sizes, colors, groupings, and complex UI assemblies.
How To Name Design Tokens
As enterprise organizations scale, building a flexible design token taxonomy that operates seamlessly across diverse products becomes a paramount engineering and design objective. This exact challenge was confronted by the team behind Intuit, the parent organization managing products such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify these varied properties under a single umbrella, the company developed a flexible token system extending far beyond individual brand themes to form a foundational architecture for multiple ecosystems.
In a detailed case study, Nate Baldwin shared vital insights into the creation of Intuit’s design token taxonomy, examining the friction points of their legacy systems and outlining the criteria established for the modern framework. Similarly, the Vodafone UK Design System team addressed the complexities of a multi-brand, multi-themed environment by publishing a Variables Taxonomy Map on Figma. This system maps out the anatomy and categorization of design tokens across four interconnected collections—spanning from brand primitives and semantics to specific page implementations—building upon established methodologies like those pioneered by Nathan Curtis.
Complementing these institutional frameworks, Romina Kavcic developed an interactive resource titled the Design Token Naming Guide alongside an accompanying token names inventory spreadsheet. These tools provide practitioners with a structured, four-tier methodology to oversee design tokens, allowing teams to incorporate new rows, themes, and modes without losing structural clarity.
Frequent Names For UI Components
When teams struggle to define standard interface elements, examining established design systems offers a reliable starting point. To mitigate the guesswork, Iain Bean compiled the Component Gallery, an extensive collection cataloging interface elements drawn from real-world design systems.
The repository features comprehensive examples for more than 50 distinct user interface components—ranging from accordions to visually hidden elements—while explicitly documenting alternative terminology used across different organizations. This repository is reinforced by auxiliary visual dictionaries such as Name That UI, providing a shared vocabulary for common interface patterns.
How To Name New Features
Beyond codebases and design systems, introducing new product features presents unique communication hurdles. Features frequently suffer from low user adoption due to poor discoverability and unclear nomenclature. Effective feature adoption requires a deliberate sequence: a user must discover the feature, understand its utility, try it, learn its mechanics, and eventually integrate it into their existing workflow.
Product strategist Erin Gannon addressed these dynamics in a practical guide examining how to name features so they are actively discovered and understood. According to Gannon’s research, successful names are fundamentally driven by user needs and problems. They should explicitly communicate the value or outcome of a feature—aligning with the "job-to-be-done" framework—while tapping directly into the natural vocabulary of the user base. Encouraging teams to listen to how customers describe a problem in their own words provides a reliable blueprint for feature naming.
Naming Products or Services
At the highest level of brand and product development, choosing a distinct name for a service or application requires rigorous exploration. Onym serves as an open-source repository organizing tools, methodologies, and resources dedicated to naming processes. The platform aggregates brainstorming frameworks, vetting strategies, etymological guides, sprint structures, and curated literature, assisting organizations in navigating the early stages of product development.
Ultimately, the most effective name is one that is clearly understood and actively shared between product teams and their users. Discrepancies often arise when designers, developers, product managers, and end-users speak in isolated dialects, generating unnecessary friction and confusion. By addressing potential naming ambiguities and maintaining a collaborative backlog to resolve terminology conflicts, cross-functional teams can streamline their workflows and build more cohesive digital experiences.
