In the world of product design and software development, choosing the right name for a variable, a color, a UI component, or a newly launched feature is rarely considered a trivial task. Language shapes how teams conceptualize problems and dictates the nature of cross-functional conversations. Yet, despite its critical importance, naming remains one of the most persistent hurdles in digital creation. Miscommunication often arises not from a lack of technical skill, but from linguistic fragmentation—where designers, developers, product managers, and users speak entirely different dialects when describing the exact same element on a screen.
This chronic friction frequently leads to bloated codebases, inconsistent design systems, poor feature discoverability, and general workplace frustration. Fortunately, a growing body of resources, design system frameworks, and expert guidelines has emerged to help teams navigate the complexities of nomenclature. By looking at how industry leaders structure everything from base-level color codes to complex multi-brand taxonomies, product teams can establish a unified vocabulary that bridges the gap between technical implementation and human intuition.
How To Name Things
Finding the right inspiration for HTML classes, CSS properties, or JavaScript functions can often feel like an isolated exercise in trial and error. When developers find themselves trapped inside traditional naming conventions, resources like Paul Robert Lloyd’s Classnames offer a refreshing antidote by encouraging teams to think outside the box.
The platform provides thematically grouped lists of words that go far beyond standard programming terminology. Instead of relying on generic descriptors, teams can explore terms rooted in nature, art, theater, music, architecture, fashion, and publishing. These collections provide nuanced words to describe behavior, likeness, order, grouping, and association, enabling engineers and designers to craft semantic, meaningful, and memorable class names that reflect the true nature of the interface.
How To Name Colors
Translating visual shades into consistent, programmatic values has long been a challenge for design system maintainers. Deciding whether a button should be "blue-600" or "ocean-breeze" can spark endless debates across design and engineering teams. To address this, David Aerne maintains a massive repository of color names containing over thirty thousand unique entries sourced from various references and thousands of user contributions.
Accompanied by a color picker and name search functionality, this extensive library serves as a vital reference for anyone struggling to standardize color palettes. Projects like Color Parrot further simplify the process by assigning intuitive names to specific color codes, ensuring that color tokens remain recognizable and contextual across disparate platforms and codebases.
How To Name Layers and Groups
Beyond code syntax, the organizational structure of design files in tools like Figma dictates how efficiently a team can scale a product. Javier Cuello has synthesized a comprehensive set of naming best practices aimed at bringing consistency and scalability to layers, groups, and components.
According to Cuello, an effective name possesses a logical structure, remains concise, carries clear meaning, is universally understood across the team, and avoids being tied strictly to temporary visual properties. By analyzing specific do’s and don’ts, designers can avoid the common trap of leaving default asset names like "Rectangle 4 copy" in production-ready files, thereby streamlining handoff processes and reducing cognitive load for incoming contributors.
How To Name Design Tokens
As organizations scale to support multi-brand and multi-product ecosystems, the challenge of token taxonomy multiplies exponentially. This was the exact challenge faced by the team at Intuit—the parent company behind household names like Mailchimp, QuickBooks, TurboTax, and Mint. To unify their digital footprint, the company engineered a flexible token system designed to transcend individual brand themes and serve as a foundational architecture across multiple products.
In a detailed case study, Nate Baldwin shared the behind-the-scenes evolution of Intuit’s design token taxonomy. The documentation outlines the pain points of their legacy systems, the strict criteria established for the new architecture, and the strategic rollout that followed. By moving away from brittle, single-use variables toward a robust, systemic approach, the team established a scalable framework that other enterprise organizations can adapt for their own design systems.
Similarly, the Vodafone UK Design System team demonstrated how to manage complex multi-brand architectures through their Variables Taxonomy Map. Built upon Nathan Curtis’s foundational work on design tokens, Vodafone’s system breaks down the anatomy and categorization of tokens across four distinct collections—moving seamlessly from brand primitives to semantics and page-level implementations. This structured approach ensures that any team member can immediately deduce where a token is used and what it represents based purely on its name.
For practitioners seeking hands-on tools to map out their own systems, Romina Kavcic developed an interactive design token naming guide and builder. Paired with a comprehensive spreadsheet inventory featuring a four-tier structure, these resources give teams a bird’s-eye view of their design tokens, allowing them to introduce new themes, modes, and rows without losing track of their architecture.
Frequent Names For UI Components
When starting a new design system or refactoring an existing one, reinventing the wheel is rarely the most efficient path. Looking at how established platforms label common interface patterns is one of the most reliable ways to resolve naming ambiguities. Iain Bean tackled this exact problem by curating the Component Gallery, a comprehensive directory that aggregates interface components from real-world design systems.
The gallery catalogs examples for more than fifty UI components—ranging from basic accordions to complex visually hidden elements—while explicitly listing alternative names used across different products. This cross-pollination of terminology helps teams align with industry standards rather than inventing idiosyncratic labels that may confuse external contributors or new hires. Complementary tools like Name That UI further reinforce this by serving as visual dictionaries for common interface patterns.
How To Name New Features
While naming internal components directly impacts developer velocity and design consistency, naming user-facing features dictates whether a product succeeds or fails in the market. Low feature adoption is frequently tied to poor discoverability rather than a lack of utility. As product designer Erin Gannon notes in her practical guide on feature nomenclature, true adoption requires a multi-step journey: a feature must first be discovered, then understood, tried, learned, and eventually integrated into a user’s existing workflow.
Effective feature names are driven by user problems and needs rather than internal corporate jargon. They should signal the tangible value or outcome of the feature—reflecting the user’s "job to be done." Gannon emphasizes the importance of adopting the user’s own language by directly asking individuals to describe a feature in their native phrasing, ensuring that marketing and interface copy resonate naturally with the audience it intends to serve.
Naming Products or Services
At the highest level of abstraction, naming a standalone product or service requires an entirely different set of exploratory methodologies. For teams embarking on brand creation, open-source repositories like Onym organize a wide array of tools, vetting frameworks, brainstorming sprints, etymological guides, and industry literature. By compiling methodologies from professional naming agencies alongside cautionary tales of past missteps, these resources encourage multidisciplinary teams to explore unconventional avenues before committing to a permanent brand identity.
Ultimately, the most effective name is one that is universally understood and actively utilized by both the internal product team and the end user. When organizations tolerate fragmented dialects—where designers, developers, product managers, and customers speak in disconnected silos—confusion and frustration inevitably follow. By auditing existing nomenclature, addressing naming conflicts proactively, and investing in shared taxonomies, product teams can build more cohesive digital experiences and collaborate with greater clarity.
