Naming is hard. Across the software development and design landscape, the language we choose not only shapes how we think about digital products, but it also dictates the conversations we have around them. From colors and icons to overarching user interface components, features, design tokens, HTML classes, and code variables, naming discrepancies frequently lead to confusion and miscommunication. When names are too generic, it becomes difficult to understand their precise intent. Conversely, when they are overly specific, they leave little room for flexibility and reuse.
To address these universal challenges, a growing number of industry creators, design system teams, and open-source contributors have developed comprehensive resources, naming conventions, and structural taxonomies. These initiatives aim to bridge the gap between different departmental dialects, reducing friction and helping teams work together more efficiently.
How to Name Things Beyond Code
When looking for inspiration for naming HTML classes, CSS properties, or JavaScript functions, developers often find themselves trapped inside conventional mental models. To help teams think outside the box, Paul Robert Lloyd created Classnames, a resource jam-packed with alternative ideas.
The platform provides thematically grouped lists of words designed to assist with naming. Users can find terms that describe different kinds of behavior, likeness between things, order, grouping, and association. Furthermore, it offers themed collections of words that might not instantly come to mind when writing code, including terminology drawn from nature, art, theater, music, architecture, fashion, and publishing.
How to Name Colors
Choosing the right name for a specific color can be equally challenging. Fortunately, David Aerne maintains a massive repository of color names known as color-names, which currently features more than 30,000 unique color names sourced from various references and thousands of user contributions.
This repository comes equipped with a color picker and name search tool, along with alternative color picker integrations. It serves as a tremendous piece of collaborative work and a fantastic reference tool for designers and developers to keep nearby when establishing color palettes.
How to Name Layers and Groups
Establishing consistency within design files is critical for scalable workflows. Javier Cuello summarized a set of naming best practices designed to help teams name their layers, groups, and components in a consistent manner.
As Cuello outlines, an effective name possesses a logical structure, remains short and meaningful, is universally understood across teams, and avoids reliance on visual properties. By establishing clear dos and don’ts, these guidelines dive into the fine details that practitioners must consider when naming sizes, colors, groups, layers, and components.
How to Name Design Tokens
Building a flexible design token taxonomy that functions seamlessly across multiple products presents a significant architectural challenge. This was the exact hurdle faced by the team at Intuit, the parent company behind major financial and productivity products such as Mailchimp, QuickBooks, TurboTax, and Mint. The organization developed a flexible token system designed to extend far beyond individual brand themes, serving instead as a foundational system for a wide array of products.
In a detailed case study, Nate Baldwin shared valuable insights into the creation of Intuit’s design token taxonomy. The documentation explores the core pain points of their legacy taxonomy system, the criteria established for the new architecture, and the implementation process, offering valuable takeaways for teams looking to build robust and adaptable token frameworks.
Similarly, the Vodafone UK Design System team addressed the complexities of a multi-brand, multi-themed design environment by publishing their Variables Taxonomy Map on Figma. The map breaks down the anatomy and categorization of design tokens into an orchestrated system of collections. Building upon Nathan Curtis’s foundational work on naming design tokens, the Vodafone framework illustrates four core collections—ranging from brand and primitives to semantics and pages—allowing anyone to instantly understand where a token is used and what it represents simply by reading its name.
Romina Kavcic also introduced an interactive tool and guide for naming design tokens, alongside a Design Token Names Inventory spreadsheet. This simple, four-level structure provides teams with a bird’s-eye view of their design tokens, enabling them to easily add rows, themes, and modes while filtering tokens without losing track of their architecture.
Frequent Names for UI Components
When struggling with nomenclature, examining what other design systems use is a practical starting point. To save teams from endless research, Iain Bean created the Component Gallery.
This repository collects interface components from real-world design systems, providing examples for more than 50 distinct UI components—ranging from accordions to visually hidden elements—while listing alternative names used across the industry. This is complemented by visual dictionaries like Name That UI, which help standardize component identification.
How to Name New Features
New features often suffer from low user adoption due to poor discoverability. Feature adoption requires a deliberate progression: a feature must first be discovered, then understood, tried, learned, and eventually integrated into existing user workflows. Erin Gannon addressed this challenge in a practical guide focused on feature naming.
According to these guidelines, successful names are driven by user needs and problems. They should signal the value or outcome of a feature—focusing on the job to be done—and crucially, tap into the user’s own language. By asking users to explain a feature in their own words, product teams can adopt vernacular that resonates immediately with their audience.
Naming Products or Services
For teams seeking names for new products or services, Onym serves as an open-source repository that organizes tools and resources for brainstorming, vetting, guidelines, sprints, etymologies, cautionary tales, and specialized naming agencies. It acts as a practical helper designed to encourage new ways of thinking during the brand creation process.
Wrapping Up
The right name is ultimately the one that is well-understood and actively used by both the internal team and the end users. Significant amounts of time are frequently lost when different departments speak about the exact same concept using separate dialects—the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect. This linguistic fragmentation is a primary driver of workplace frustration and confusion.
When feature adoption lags or cross-functional friction arises, the root cause is often as simple as nomenclature. By proactively identifying and addressing naming conflicts, development and design teams can reduce confusion and streamline collaboration across the board.
