In the intricate world of digital product development, there is an old adage often whispered in engineering circles: "There are only two hard things in Computer Science: cache invalidation and naming things." While this is a playful jab at the complexity of software architecture, the reality for UI/UX designers and developers is far more grounded. The language we choose to define our components, tokens, and features does more than just populate code; it shapes our mental models, influences team collaboration, and ultimately dictates how users interact with our digital ecosystems. Poor naming is a silent killer of productivity. When a design system uses overly generic terminology—such as box-1 or blue-primary-v2—it creates friction. When names are too specific—like sidebar-login-button-desktop—they break under the pressure of modern, responsive design. To bridge the gap between design and development, we must master the art of taxonomy. The Foundations: Why Naming Matters The language used within a team acts as the "source of truth." When a designer calls a component an "Accordion" and a developer refers to it as a "Collapsible Panel," the resulting confusion leads to bugs, bloated code, and a disjointed user experience. This "dialect barrier" is common across cross-functional teams, where designers, product managers, and engineers all operate with different vocabularies. Effective naming is the antidote to this friction. It establishes a shared language that allows for scalable, maintainable, and accessible digital products. By focusing on intent rather than visual appearance, teams can build systems that evolve alongside their products. Chronology of a Naming Strategy A robust naming strategy does not happen overnight. It is an iterative process that evolves through several stages of the product lifecycle: Discovery & Auditing: The initial stage involves inventorying existing assets. This is where teams often discover "naming sprawl," where similar components have evolved different names across different product versions. Standardization: Establishing a hierarchy. During this phase, teams define a taxonomy—often inspired by systems like Atomic Design—to categorize tokens, components, and variables. Documentation & Tooling: Implementing the naming convention into the design system and code repositories. This includes utilizing tools like Figma libraries and CSS naming conventions (BEM, CSS Modules, etc.). Refinement: As the product grows, the naming system must be stress-tested. If a new feature breaks the existing naming logic, the taxonomy must be adjusted. Governance: Maintaining the integrity of the names. This involves peer reviews and documentation updates to ensure that new team members adhere to the established conventions. Supporting Resources and Tooling The burden of naming does not have to fall on the individual designer or developer alone. The open-source community has developed a wealth of resources to streamline this process. Inspiration for UI Components and Classes When you hit a creative wall, Classnames serves as an invaluable resource. It provides thematically grouped lists of words that encourage developers to think beyond functional descriptions. By categorizing terms into themes—such as architecture, nature, and music—it helps teams find names that are evocative, memorable, and distinct. Color Taxonomy: Beyond Hex Codes Naming colors is notoriously difficult. The standard "blue-dark" or "light-gray" is often insufficient for modern design systems that require semantic clarity. Color Parrot is a standout tool in this space, maintaining a repository of over 30,000 unique color names. By providing a common name for a specific hex value, it ensures that every stakeholder—from the brand manager to the frontend developer—is referring to the exact same hue. The Component Gallery For those struggling to name UI elements, the Component Gallery by Iain Bean is a gold standard. It acts as an ethnographic study of real-world design systems. By aggregating how industry leaders name over 50 common components, it allows teams to see the "industry standard" for everything from accordions to visually hidden elements. Similarly, Name That UI provides a visual dictionary that is particularly useful for new designers looking to align their vocabulary with established patterns. Official Methodologies and Case Studies Industry leaders have moved beyond ad-hoc naming to sophisticated, algorithmic taxonomies. The Intuit Approach: Flexible Token Systems Nate Baldwin’s work at Intuit remains a benchmark for scalability. When managing a portfolio that includes diverse products like Mailchimp and QuickBooks, a rigid naming system fails. Intuit’s solution was to create a flexible design token taxonomy that separates "brand" from "product" tokens. By defining a clear hierarchy—from primitives (base values) to semantic tokens (intent-based values)—they created a system that is robust enough to support a massive, multi-product ecosystem. The Vodafone Variable Taxonomy The Vodafone UK Design System team has taken this a step further with their Variables Taxonomy Map. This approach categorizes tokens into four distinct layers: Brand, Primitives, Semantics, and Pages. By mapping the relationship between these layers, the team created a "source of truth" that allows anyone to understand the intent and application of a token simply by reading its name. This is a direct application of Nathan Curtis’s influential work on naming design tokens, proving that a well-structured taxonomy is as vital as the visual design itself. Implications for Feature Adoption Naming is not just an internal concern; it has massive implications for user adoption. Erin Gannon, in her guide "What Do We Call This Thing?", highlights that features often suffer from low adoption not because they lack utility, but because they lack discoverability. When a feature is named using "corporate speak" or overly technical jargon, users struggle to map the feature to their own problems. The most effective names are those that reflect the Jobs-to-be-Done (JTBD) framework. A good name should signal the value or outcome of a feature, utilizing the language of the user rather than the language of the product team. If your users call a process "scheduling," do not name the feature "Task Orchestration." The Path Forward: Best Practices To summarize the collective wisdom of the design community, here are the core principles for effective naming: Be Meaningful, Not Literal: Avoid naming elements after their color or position (e.g., red-right-button). Instead, name them after their function (e.g., danger-action-button). Prioritize Consistency: Ensure that the same component has the same name across design files, code repositories, and documentation. Keep it Short: Names should be descriptive but concise. If a name requires a paragraph of explanation, it is too complex. Use User-Centric Language: For product features, borrow terminology from your user interviews. Plan for Scale: Always consider how a name will function in a multi-brand or multi-theme environment. Conclusion Naming is the invisible infrastructure of a successful product. It is the bridge between the conceptual world of the designer and the functional world of the developer. As we continue to build more complex, accessible, and inclusive digital environments, the importance of a shared, well-structured vocabulary will only grow. By leveraging the tools and frameworks provided by the open-source community, and by adopting a more intentional approach to our internal taxonomies, we can eliminate the "dialect barriers" that plague our teams. The goal is to reach a point where the name of a component, token, or feature is so intuitive that it requires no explanation at all—allowing the team to focus on what truly matters: building great products. Editor’s Note: This guide is intended as a living resource for design and engineering teams. We encourage you to bookmark the tools mentioned, such as the Design Token Naming Guide and Onym, to assist in your next design system audit. As always, we are grateful to the creators who open-source their methodologies for the benefit of the entire web community. Post navigation Jean Prouvé’s 1944 Demountable House Reimagined as a Japanese Tea Pavilion at Design Miami.Paris Beyond the Chronological Graveyard: How Museum Department Is Reshaping Contemporary Graphic Design Curation
