The language used in digital software development shapes not only how product teams construct interfaces, but also how engineers, designers, product managers, and end users understand them. Yet across the software industry, naming conventions remain one of the most persistent operational friction points. Miscommunication routinely arises when naming user interface components, color palettes, visual icons, HTML classes, CSS properties, and design variables.
When names are structured too broadly, they become ambiguous and fail to communicate their underlying intent. Conversely, when names are overly specific, they restrict design flexibility and prevent effective code reuse across applications. Resolving this tension requires a deliberate approach to vocabulary and systemic categorization. Industry leaders, design system engineers, and open-source contributors are actively developing specialized frameworks, taxonomies, and references to establish clear, scalable naming conventions across digital products.
How To Name Things
Finding appropriate nomenclature for HTML classes, CSS properties, or JavaScript functions often presents a creative bottleneck for software engineers. When developers default to rigid technical descriptions, the resulting code can become fragile and difficult to maintain. To address this issue, web creator Paul Robert Lloyd developed Classnames, an open-source reference library designed to encourage expansive semantic thinking when structuring web stylesheets and codebases.
The resource organizes vocabulary into thematic groupings, helping developers identify precise terms based on spatial logic, structural hierarchy, behavioral characteristics, and relational associations. Rather than relying strictly on standard programming jargon, Classnames curates collections of words drawn from external disciplines, including architecture, nature, music, theater, art, fashion, and print publishing. By drawing from these rich taxonomies, developers can construct intuitive, highly descriptive class names and functional primitives that remain meaningful over long product lifecycles without tying code directly to fleeting visual aesthetics.
How To Name Colors
Establishing systematic names for color palettes poses a distinct challenge within digital design systems. While engineers frequently rely on raw hexadecimal codes, RGB values, or functional variables, human-readable names are necessary for seamless communication across multidisciplinary teams. To solve this problem at scale, developer David Aerne maintains a comprehensive open-source color repository containing 30,355 unique color names compiled from diverse linguistic references and thousands of individual community contributions.
Aerne’s project is backed by specialized color pickers, automated search interfaces, and lookup tools such as Color Parrot, an application that assigns distinct, readable titles to precise visual color coordinates. By mapping precise color values to curated titles, design teams can systematically organize complex design tokens and color swatches. This removes ambiguity when transitioning color palettes from initial design files into production code bases.
How To Name Layers and Groups
In digital product design tools, unorganized layer structures routinely slow down cross-functional workflows. When design files are populated with generic layer designations like "Rectangle 42" or "Group 12," software engineers face unnecessary friction during design handoff. Design consultant Javier Cuello summarized a series of structural guidelines aimed at standardizing layer, group, and component nomenclature within design files.
According to Cuello’s framework, an effective naming system must maintain a logical, predictable hierarchy while remaining concise, universally recognizable, and completely independent of superficial visual properties. For instance, naming a primary interaction element based on its visual appearance—such as "blue-button"—creates immediate technical debt if the design token later shifts to a different hue. Cuello highlights critical practices for team leads, contrasting rigid visual naming against resilient semantic structures, while offering actionable frameworks for sizing tiers, component grouping, and layer management.
How To Name Design Tokens
Creating a resilient design token system becomes exponentially more difficult when managing multi-brand, multi-product enterprise environments. This was the exact challenge faced by the design engineering group at Intuit, the parent organization behind diverse consumer and business platforms including Mailchimp, QuickBooks, TurboTax, and Mint. The engineering team needed to construct a flexible design token architecture capable of scaling far beyond a single visual brand identity.
Design system strategist Nate Baldwin documented the evolution of Intuit’s token architecture in a detailed technical case study. Baldwin outlined the operational limitations of Intuit’s legacy token taxonomy, detailing the foundational criteria established to build a universal, multi-brand platform system. The resulting case study details how enterprise organizations can break down token tiers into logical semantic layers, allowing distinct brand platforms to share a unified structural foundation while retaining independent visual themes and operational flexibility.
Frequent Names For UI Components
When team members debate what to call a given interface element, looking at industry-wide consensus offers valuable clarity. Rather than inventing isolated naming conventions from scratch, design system teams routinely benchmark their decisions against established industry design systems. To streamline this research process, developer Iain Bean created the Component Gallery, an curated repository of user interface components aggregated from real-world enterprise design systems.
The Component Gallery catalogs real-world implementation examples across more than 50 standard UI component categories, ranging from standard accordions to accessibility utilities like visually hidden structural elements. Crucially, the platform maps out the alternate terms that different design systems assign to identical interface patterns. This resource, alongside visual dictionaries such as Name That UI, allows product teams to analyze cross-industry terminology patterns, adopt widely recognized component names, and minimize cognitive friction for incoming developers.
How To Name New Features
Feature adoption in digital software products frequently stalls due to poor discoverability rather than flawed core functionality. For a feature to achieve sustained usage, end users must first discover its existence, comprehend its primary purpose, attempt to use it, master its interaction patterns, and seamlessly incorporate it into their existing daily routines. User experience strategist Erin Gannon authored an analysis focusing on how strategic product naming directly influences this adoption cycle.
Gannon emphasizes that feature titles must be rooted directly in user needs rather than internal engineering codenames or marketing jargon. Effective feature names articulate the core value proposition or outcome—often referred to in design methodology as the user’s "job-to-be-done." To achieve this alignment, product teams are advised to conduct user research where participants describe a tool’s functionality in their own unscripted vocabulary. By directly adopting the language used naturally by target users, product managers can significantly improve feature comprehension and long-term user retention.
How To Name Variables (Taxonomy Map)
Managing variables across multi-themed, multi-brand digital ecosystems requires a rigorous structural taxonomy. The design system team at Vodafone UK developed a comprehensive Variables Taxonomy Map on Figma to define the explicit anatomy and functional classification of design tokens across their enterprise footprint.
Vodafone UK’s model categorizes design variables across four distinct structural collections, illustrating how tokens transition from core brand primitives to contextual semantic tokens and page-level variables. Building upon the foundational design token research of strategist Nathan Curtis, Vodafone’s taxonomy enables engineers and designers to immediately identify a variable’s precise role, context, and usage parameters simply by reading its systematic name. This structured naming path eliminates ambiguity when applying variable styles across complex web interfaces.
Design Token Naming Guide + Inventory
To assist teams in creating customized token naming structures from the ground up, design system advisor Romina Kavcic created the Design Token Naming Guide + Builder. The interactive platform guides product teams through the foundational mechanics of design tokens, offering a practical workspace to configure custom token syntax by combining structural categories, component contexts, interaction states, and functional roles.
To complement the builder framework, Kavcic introduced a Design Token Names Inventory spreadsheet. The inventory model utilizes a structured four-level hierarchy, providing design operations managers with a comprehensive overview of their entire design system token catalog. This structured format allows technical leads to manage themes, configure dark and light display modes, and systematically filter token inventories without losing track of underlying code dependencies.
Naming Products or Services
For organizations seeking to name new software products, digital services, or internal platforms, the open-source directory Onym serves as a specialized repository of structural naming frameworks and brainstorming tools. Curated to support product strategists, Onym organizes resources covering etymological research, linguistic vetting, naming sprint methodologies, and legal verification guides.
The repository collates analytical references alongside cautionary case studies and curated tools, helping product leaders navigate the strategic and creative complexities of brand architecture. By applying structured methodologies to high-level product naming, organizations can avoid common trademark pitfalls and ensure that new product titles resonate effectively within competitive digital markets.
Overcoming Communication Dialects in Product Teams
Ultimately, an effective name is one that is universally understood and consistently applied across an entire organization. Significant time and resources are routinely lost in software development when cross-functional teams attempt to communicate using fundamentally different technical dialects. Designers often speak in visual terms, developers think in structural or algorithmic primitives, product managers focus on business metrics, and end users interact through task-oriented mental models.
When a digital feature suffers from low adoption or internal friction, the root cause can frequently be traced back to confusing or contradictory terminology. Identifying naming conflicts early and treating vocabulary fixes as essential product maintenance allows teams to eliminate cross-functional confusion. Establishing a clear, shared vocabulary remains one of the most effective strategies for reducing friction, accelerating product velocity, and building cohesive web software.
