In software engineering and digital product design, establishing a clear, standardized vocabulary remains one of the most complex challenges facing development teams. As digital ecosystems scale across multiple platforms, brands, and codebases, the language used to define user interface components, color palettes, design tokens, and functional variables often degenerates into a confusing web of competing terms.
Designers, software engineers, product managers, and end-users frequently describe identical interface elements using entirely different dialects. A designer might refer to an element based on its visual appearance, a developer might name it after its functional logic, and a product manager might align it with a specific business capability. This linguistic fragmentation creates technical debt, slows feature adoption, and leads to miscommunications during the product development lifecycle.
To address this persistent issue, design systems leaders and open-source contributors have developed a comprehensive ecosystem of naming frameworks, taxonomy maps, and specialized tools. From enterprise token structures at global corporations to curated component galleries, these initiatives aim to replace guesswork with structured, scalable systems for naming digital artifacts.
The Core Dilemma: Balancing Generic and Specific Language
The difficulty of naming in technology stems from a fundamental tension between abstraction and precision. When teams select names for HTML classes, CSS custom properties, or JavaScript functions, they frequently fall into one of two traps: choosing names that are either overly generic or excessively specific.
When an interface element or variable is given an overly generic name, its scope and purpose become ambiguous, leading to misuse or accidental overrides across codebases. Conversely, when a name is tied too tightly to a specific context, visual style, or location—such as naming a button .blue-sidebar-button—it loses its flexibility. Should that button later be moved to a header or changed to green during a brand refresh, the name becomes misleading, requiring tedious refactoring across multiple repositories.
The language chosen to represent software artifacts ultimately shapes how engineering teams conceptualize and interact with their systems. As design systems continue to mature from basic UI kits into complex, multi-brand frameworks, establishing clear conventions for how elements are structured and categorized has evolved from a minor administrative detail into a core architectural requirement.
Expanding Linguistic Horizons in Development
To assist developers in finding naming inspiration beyond rigid technical jargon, creator Paul Robert Lloyd developed Classnames, an open-source reference tool designed to encourage creative thinking when constructing HTML classes, CSS properties, and function names.
Rather than relying on repetitive code conventions, the platform organizes language into thematically grouped collections. By drawing vocabulary from fields such as architecture, nature, art, music, fashion, theater, and publishing, the resource helps engineers identify descriptive terms for behaviors, structural relationships, ordering, and grouping.
For instance, leveraging terms from architectural design or theatrical staging can provide intuitive metaphors for layout structures, component hierarchies, and state management. By broadening the pool of potential terminology, teams can establish internal conventions that remain expressive without becoming tied to transient visual traits.
Systematizing Color Directories and Visual Attributes
Color management presents another major naming hurdle in UI design. In many codebases, color declarations historically relied on raw hexadecimal values or overly simplistic labels such as light-blue or dark-red. As design systems expanded to support dark mode, custom themes, and accessibility standards, these rudimentary labels quickly proved unsustainable.
To solve the challenge of categorizing color spaces, developer David Aerne created a comprehensive open-source color names repository. The database contains over 30,355 unique color names, compiled from extensive research and thousands of user contributions.
To make this database accessible to software teams, the initiative includes utilities like Color Parrot, an automated naming service that maps raw color hex codes to precise textual labels. Supported by interactive color pickers and search interfaces, the repository allows design systems engineers to replace arbitrary color codes with standardized semantic references. Having access to a unified dictionary of color names helps teams bridge the gap between design software and production code, ensuring that brand guidelines remain consistent across various platforms.
Structural Best Practices for Layers, Groups, and Components
Beyond individual variables and tokens, the structural organization of canvas layers, component groups, and visual files significantly influences cross-functional collaboration. Design strategist Javier Cuello outlined a framework of industry best practices aimed at creating scalable, predictable names across design tools and code repositories.
According to these guidelines, an effective naming system must adhere to several key criteria:
- It must possess a clear, logical structure.
- It must remain concise yet meaningful.
- It must be universally understood by both designers and engineers.
- It must be abstracted away from specific, volatile visual properties.
Cuello emphasizes that naming elements after their visual traits—such as size, color, or exact placement—inevitably leads to broken logic when design parameters evolve. Instead, names should reflect the functional role or semantic purpose of the element within the system. By establishing strict rules for how layers, groups, and master components are organized, teams prevent design files from becoming cluttered and difficult to navigate for downstream developers.
To further standardize component terminology across the industry, researcher Iain Bean curated The Component Gallery. This repository aggregates interface components from hundreds of real-world enterprise design systems, offering a clear view of how different organizations name and structure common UI elements.
Covering dozens of foundational components—ranging from basic accordions and progress indicators to complex data tables and visually hidden utility wrappers—the platform documents the primary and alternate names used across major design systems. Supplementary visual dictionaries, such as Name That UI, provide additional reference points for teams seeking industry-standard terminology for complex interface patterns.
Enterprise Design Token Taxonomies: Scalability Across Multi-Brand Systems
As software ecosystems expand through mergers, acquisitions, and multi-product lines, managing design systems across disparate brands requires highly flexible token taxonomies. Design tokens—the foundational sub-atomic values that store design decisions such as colors, typography, spacing, and elevation—must be named systematically to ensure seamless mapping between design software and code.
A notable example of enterprise token taxonomy comes from Intuit, the parent organization behind products including TurboTax, QuickBooks, Mailchimp, and Mint. Design systems architect Nate Baldwin documented Intuit’s transition to a flexible token framework capable of scaling across multiple distinct product lines and brand identity systems.
Intuit’s legacy system suffered from rigid, brand-specific naming structures that hindered reusability and cross-product consistency. To overcome these constraints, the team established a tiered taxonomy that separates global primitives from semantic context and component-specific implementations. This architectural separation allows global base colors to be mapped to functional semantic concepts—such as interactive surface backgrounds or validation state borders—without locking the design system into a single brand identity.
Similarly, the team behind the Vodafone UK Design System published their Variables Taxonomy Map, a community resource that details the structural taxonomy of design tokens within complex, multi-themed enterprise environments. Building upon foundational token research by design systems strategist Nathan Curtis, Vodafone’s framework categorizes tokens across four distinct collections:
- Brand Primitives: The raw, un-contextualized values that define a brand’s visual identity.
- Global System Tokens: Standardized structural choices for layout, spacing, and typography scale.
- Semantic Tokens: Context-aware design decisions that dictate state, interactive feedback, and surface roles.
- Page and Component Variables: High-level abstractions bound directly to specific UI components and view templates.
By establishing a clear lineage from primitive brand values down to page-level variables, any member of the engineering or design team can instantly discern the purpose, scope, and implementation context of a variable simply by analyzing its name.
Complementing these enterprise frameworks, product designer Romina Kavcic created the Design Token Naming Guide + Builder, an interactive utility designed to help teams construct custom token structures. The platform breaks token construction down into systematic parameters—including category, type, item, sub-item, state, and role—allowing teams to configure consistent token structures suited to their specific architectural needs. Kavcic also developed a four-level inventory spreadsheet that provides product teams with a clear overview of their active token suites, enabling multi-theme filtering and state management.
Aligning Feature Terminology with User Mental Models
While technical variables and system tokens require strict architectural logic, the naming of customer-facing product features demands an approach rooted in user research and cognitive accessibility. Low adoption rates for newly launched software capabilities can frequently be traced to poor discoverability caused by confusing or developer-centric terminology.
UX writer and researcher Erin Gannon highlights that for a feature to achieve widespread adoption, users must first discover it, comprehend its function, test its capabilities, and seamlessly integrate it into their existing daily workflows. When features are given abstract, internal project code names or marketing jargon, users struggle to understand their practical value.
Effective feature names are centered around user outcomes and explicit goals—often framed around the concept of "jobs-to-be-done." Design teams are encouraged to conduct qualitative research, observing how users describe their pain points and workflows in their own words. By adopting the user’s authentic vocabulary rather than internal engineering terms, product teams can drastically reduce the cognitive friction required to adopt new functionality.
For broader product and platform naming efforts, open-source initiatives such as Onym provide structured directories encompassing brainstorming tools, vetting methodologies, etymological guides, and naming sprint frameworks. These resources help teams rigorously evaluate candidate names for clarity, international suitability, legal availability, and brand alignment before public launch.
Eliminating Dialect Barriers in Product Development
The overarching goal of standardizing naming conventions across design systems, codebase variables, and product features is to eliminate communication friction between discipline silos. When designers, frontend engineers, product managers, and end-users use disparate terms for identical concepts, development velocity drops and user confusion increases.
By implementing clear, objective taxonomy frameworks—such as semantic design tokens, structured component galleries, and user-centric feature labels—organizations can build a unified operational language. Identifying and resolving naming conflicts early in the product development lifecycle prevents technical debt and ensures that design systems can scale efficiently alongside the business.
