Naming things in design and software development has long been considered one of the industry’s most persistent challenges. The vocabulary teams choose not only shapes how they conceptualize interfaces, digital assets, and underlying code architectures, but it also dictates the quality of communication across cross-functional groups. This inherent difficulty often leads to widespread confusion regarding colors, icons, user interface components, and features. Consequently, engineers, product managers, and designers frequently struggle to establish clear, scalable names for design tokens, HTML classes, and variables.
Choosing the right name requires striking a delicate balance. Often, the identifiers chosen during the early stages of a project are either overly generic—making it difficult to understand their precise intent—or excessively specific, leaving little room for flexibility, scalability, and code reuse. Navigating this challenge demands an understanding of established naming conventions, industry resources, and structured taxonomies that align the mental models of designers, developers, and end-users alike.
How To Name Things
When development and design teams look for inspiration when naming HTML classes, CSS properties, or JavaScript functions, finding the right terminology can be a creative bottleneck. To help professionals think outside the box, Paul Robert Lloyd maintains Classnames, a resource jam-packed with ideas and vocabulary designed to spark fresh perspectives.
The platform provides thematically grouped lists of words that are well-suited for code architecture and design structures. Users can explore terms describing behavior, likeness, order, grouping, and association, alongside themed collections drawn from unexpected domains such as nature, art, theater, music, architecture, fashion, and publishing. By broadening the linguistic palette beyond standard technical jargon, teams can construct more evocative and contextually appropriate identifiers.
How To Name Colors
Establishing a standardized, scalable approach to naming colors presents another layer of complexity, particularly when scaling across multiple brands and themes. To address this challenge, David Aerne maintains a comprehensive repository of color names. Currently housing more than 30,000 unique color designations sourced from various references and thousands of user contributions, the repository serves as an invaluable reference point for digital creators.
Complete with an integrated color picker, name search functionality, and multiple configuration options via platforms like CodePen, the repository bridges the gap between raw hexadecimal or RGB values and human-readable semantics. Having a reliable, extensive reference nearby helps teams avoid arbitrary color naming conventions that often plague large-scale design systems.
How To Name Layers and Groups
Within collaborative design environments like Figma, messy layer panels can severely hinder productivity and handoff efficiency. Javier Cuello has summarized a definitive set of naming best practices aimed at helping teams name their layers, groups, and components in a consistent, scalable manner.
According to these guidelines, an effective name possesses a logical structure, remains concise, carries clear meaning, is universally understood across the organization, and avoids direct ties to temporary visual properties. By establishing clear do’s and don’ts, design systems teams can eliminate ambiguity, ensuring that digital assets remain organized as projects scale across multiple contributors and product teams.
How To Name Design Tokens
Building a flexible design token taxonomy that functions seamlessly across a diverse ecosystem of products remains a primary objective for enterprise organizations. This exact challenge was faced by the team at Intuit, the parent company behind widely used financial and productivity tools such as Mailchimp, QuickBooks, TurboTax, and Mint. To unify their digital presence, the company developed a flexible token system designed to serve as a foundational architecture transcending individual brand themes.
Nate Baldwin detailed the creation of this architecture in a comprehensive case study examining Intuit’s design token taxonomy. The insights highlight the core pain points of legacy taxonomy systems, outline the criteria established for the redesigned infrastructure, and provide actionable takeaways for organizations seeking to build their own robust token hierarchies.
Similarly, the Vodafone UK Design System team addressed the complexities of managing a multi-brand, multi-themed ecosystem by releasing their Variables Taxonomy Map. Built upon foundational work by Nathan Curtis, the map breaks down the anatomy and categorization of design tokens into a structured system of collections. Spanning from brand primitives and semantics to page-level applications, this taxonomy ensures that team members can instantly determine where a token is used and what it represents simply by inspecting its name.
Complementing these enterprise methodologies, Romina Kavcic developed a dedicated design token naming guide and interactive builder. This tool helps practitioners understand token mechanics while configuring custom naming structures incorporating components, categories, states, and roles. Paired with a structured spreadsheet inventory, these resources provide a bird’s-eye view of design tokens, allowing teams to manage themes, modes, and filters without losing structural integrity.
Frequent Names For UI Components
When teams struggle with component nomenclature, examining how other organizations approach similar interface elements offers an efficient starting point. To spare designers and developers from getting lost in the research rabbit hole, Iain Bean created the Component Gallery, an archive cataloging interface components sourced directly from real-world design systems.
The gallery features comprehensive examples across more than fifty distinct UI components—ranging from accordions to visually hidden utility classes—while documenting alternative names used across the industry. This collection is further supplemented by visual dictionaries such as Name That UI, providing a clear reference for standard interface nomenclature.
How To Name New Features
While technical nomenclature impacts internal workflows, the terminology chosen for user-facing features directly dictates product adoption. Features frequently suffer from low engagement due to poor discoverability. Feature adoption is a gradual journey: users must first discover a feature, understand its value, try it out, learn its mechanics, and eventually integrate it into their existing workflows.
Erin Gannon addressed this challenge in a practical guide focused on feature naming. Effective feature names must be driven by user needs and core problems, signaling the tangible value or outcome of the feature rather than internal technical specifications. By tapping directly into the language users employ when describing their own workflows—gathered through direct user research—teams can bridge the gap between product capabilities and customer comprehension.
Naming Products or Services
Moving beyond interface components and code, naming standalone products or services requires an entirely different strategic approach. Onym serves as an open-source repository that aggregates tools, brainstorming frameworks, vetting methodologies, sprints, and etymological resources. By compiling guides, cautionary tales, and industry resources, the repository provides creators with structured frameworks to navigate the complexities of brand and product nomenclature.
Wrapping Up
Ultimately, the most effective name is one that is universally understood and actively utilized by both the internal team and the end-users. Countless hours are frequently wasted when designers, developers, product managers, and customers speak about the same conceptual entity using entirely different professional dialects. This linguistic fragmentation is a primary driver of operational friction and user confusion.
Addressing these discrepancies often requires evaluating terminology before attributing low adoption rates solely to functionality or design layout. By acknowledging potential naming conflicts and maintaining a dedicated backlog to refine organizational vocabulary, teams can significantly reduce friction, streamline collaboration, and establish a shared language that scales alongside their digital products.
