Naming things in design and development is notoriously difficult. The language teams choose not only shapes how they think about digital products, but it also dictates the clarity and effectiveness of everyday conversations. This fundamental challenge often leads to widespread confusion regarding colors, icons, UI components, and product features, while simultaneously complicating the process of establishing clear design tokens, HTML classes, and code variables.
When professionals choose names, they frequently oscillate between two extremes. Names are occasionally made far too generic, rendering it nearly impossible to understand the exact intent or context. Conversely, they can be made overly specific, severely restricting flexibility, scalability, and future reuse. Finding the precise middle ground requires an understanding of naming conventions, structured taxonomies, and strategic thinking. To help teams navigate these hurdles, a growing ecosystem of open-source repositories, design system inventories, and practical guides has emerged to streamline the naming process across disciplines.
How To Name Things
For developers and designers seeking fresh inspiration when naming HTML classes, CSS properties, or JavaScript functions, resources like Classnames offer a creative departure from conventional terminology. Created by Paul Robert Lloyd, the platform provides thematically grouped lists of words designed to encourage professionals to think outside the box.
Rather than relying on tired, repetitive naming conventions, the site catalogs terms that describe behavior, likeness, order, grouping, and association. It also incorporates unexpected, themed collections drawn from nature, art, theater, music, architecture, fashion, and publishing. These alternative vocabularies give teams a broader palette of words to draw from when standard technical terminology falls short or creates ambiguity in large codebases.
How To Name Colors
Establishing a standardized, logical approach to naming colors remains a persistent challenge for digital product teams. To address this, David Aerne maintains an extensive repository of color names known as color-names, which currently catalogs more than 30,000 unique color designations sourced from diverse references and thousands of user contributions.
The project features an interactive color picker and name search functionality, complemented by various integrations via GitHub. This massive database serves as a vital reference tool for developers and designers who need to move beyond arbitrary hex codes or overly simplistic descriptive names, providing a shared vocabulary for color systems across multi-brand environments.
How To Name Layers and Groups
Within design tools like Figma, the lack of consistent layer and group naming can quickly turn a shared file into an unmanageable workspace. Javier Cuello addressed this operational bottleneck by compiling a comprehensive set of design guidelines focused specifically on naming layers, groups, and components in a scalable manner.
According to Cuello’s best practices, an effective name possesses a logical structure, remains concise and meaningful, is universally understood across cross-functional teams, and deliberately avoids tying itself to superficial visual properties. By outlining clear do’s and don’ts, the guidelines help teams navigate the finer details of labeling sizes, colors, structural groupings, and complex UI components without descending into organizational chaos.
How To Name Design Tokens
Scaling a design system across multiple major brands and products presents significant architectural hurdles, particularly when it comes to naming design tokens. This exact challenge was confronted by the team at Intuit, the parent organization behind widely used platforms such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify their ecosystem, the company developed a flexible token taxonomy capable of transcending individual brand themes to serve as a foundational architecture for diverse software products.
In a detailed case study, Nate Baldwin shared the behind-the-scenes process of creating Intuit’s design token taxonomy. The documentation outlines the specific pain points of their legacy systems, the strategic criteria established for the redesign, and the eventual implementation of a more robust structure. The insights provide valuable lessons for organizations attempting to build scalable, multi-product design token hierarchies.
Similarly, the Vodafone UK Design System team tackled the complexities of a multi-brand, multi-themed architecture by releasing their Variables Taxonomy Map on Figma. Built upon the foundational work of Nathan Curtis regarding design token nomenclature, Vodafone’s map breaks down the anatomy and categorization of tokens across four distinct collections—moving systematically from brand and primitives to semantics and page-level applications. This structured mapping allows team members to instantly understand where a token is utilized and what it represents based entirely on its name.
Romina Kavcic has further contributed to this space by developing an interactive design token naming guide and builder. Paired with a comprehensive design token names inventory spreadsheet, the tool provides a four-level hierarchical structure that gives teams a bird’s-eye view of their entire token inventory, allowing them to filter, expand, and manage themes and modes efficiently.
Frequent Names For UI Components
When teams struggle to name interface elements, examining established real-world design systems provides an immediate benchmark. To save designers and developers from getting lost in endless design system research, Iain Bean built the Component Gallery.
The gallery collects real-world interface components from dozens of design systems, covering more than 50 distinct UI elements—ranging from accordions to visually hidden utilities. Alongside practical examples, the resource catalogs the alternative names these components go by across the industry. This is further supplemented by Name That UI, a visual dictionary designed to help practitioners quickly identify and correctly label common interface components.
How To Name New Features
While technical components require internal clarity, product features demand external discoverability. Low feature adoption is frequently tied not to the utility of the feature itself, but to poor naming that fails to resonate with users. True feature adoption takes time; users must first discover a feature, understand its value, test it, learn its mechanics, and eventually integrate it into their existing workflows.
In a practical guide on feature naming, Erin Gannon emphasizes that effective feature names must be driven by genuine user needs and problem-solving metrics. Successful names clearly signal the ultimate value or outcome of a feature—focusing heavily on the job-to-be-done—while deliberately adopting the vocabulary used by the users themselves. By actively listening to how users describe their problems in their own words, product teams can bridge the gap between internal product terminology and customer understanding.
Naming Products or Services
For organizations embarking on the broader journey of naming entirely new products, services, or companies, Onym serves as an open-source repository of tools and methodologies. The platform aggregates brainstorming frameworks, vetting exercises, strategic guides, etymological resources, sprint methodologies, and recommended literature, helping teams navigate the creative and commercial complexities of brand naming.
Ultimately, the most effective name is one that is universally understood and actively utilized by both the internal team and the end users. Miscommunication often arises when designers, developers, product managers, and users speak in separate disciplinary dialects about the exact same underlying concept. By addressing naming conflicts early and treating nomenclature as an integral part of product strategy, organizations can significantly reduce daily friction and foster more cohesive cross-functional collaboration.
