"Naming is hard." It is a mantra echoed in every design studio and engineering office across the globe. Yet, despite its difficulty, it remains one of the most critical components of a successful digital product. The language we use does more than just identify a button or a color; it shapes our cognitive model, dictates our team’s communication, and ultimately influences the user’s perception of the product.
When we struggle to name design tokens, HTML classes, or JavaScript functions, we aren’t just facing a linguistic hurdle—we are facing a structural one. Poor naming conventions lead to confusion, fragmented design systems, and ultimately, low feature adoption. This article explores the methodologies, resources, and best practices for mastering the art of naming in the digital landscape.
The Core Philosophy: Why Naming Matters
The challenge with naming often boils down to two extremes: terms that are too generic, rendering them meaningless in a specific context, or terms that are too specific, effectively killing any chance for reuse or scalability.
The goal of a robust naming system is to create a "common language" that bridges the gap between designers, developers, product managers, and users. When these groups speak different "dialects"—using different terms for the same component—friction is inevitable. By standardizing our nomenclature, we reduce the cognitive load on our teams and ensure that the mental models of those building the product align with the mental models of those using it.
Chronology of Naming: From Conceptualization to Implementation
The process of naming is not a final step; it is an iterative journey.
- Discovery (The "What"): Identifying the core purpose of a component, token, or feature.
- Taxonomy Building (The "How"): Establishing a hierarchy. For design systems, this often moves from primitive tokens (base values) to semantic tokens (intent-based) to component-specific tokens.
- Refinement (The "Who"): Aligning the name with the user’s language rather than the internal technical jargon.
- Implementation & Documentation: Codifying the name within the design system and codebase to ensure consistency across products.
Supporting Data and Essential Resources
To aid in this process, several industry-leading resources have emerged, providing both inspiration and structural frameworks.
1. The Power of Thematic Grouping
For developers stuck in a "div-class-wrapper" rut, Classnames offers a refreshing perspective. It provides thematically grouped lists of words that encourage developers to look beyond standard functional naming. Whether you are seeking terms related to architecture, music, or nature to describe component behavior or grouping, this resource acts as a cognitive catalyst for more descriptive, logical naming.
2. Standardizing Color Nomenclature
Managing color palettes across large-scale design systems is notoriously complex. Color Parrot offers a repository of over 30,000 unique color names. This is not just a naming tool; it is a reference for consistency, ensuring that "Cerulean Blue" is never confused with "Sky Blue" in your global styles.
3. Best Practices for Layers and Components
Javier Cuello’s naming guidelines serve as a foundational text for design teams. Cuello emphasizes that a good name must be:
- Logical: Based on a clear, consistent structure.
- Meaningful: Descriptive of the item’s function rather than its visual appearance (e.g., use "Primary-Button" instead of "Blue-Rectangle").
- Accessible: A name that is easily understood by any new team member.
Case Study: Intuit’s Flexible Token Taxonomy
The team at Intuit faced the monumental challenge of creating a design token system that served a diverse portfolio, including Mailchimp, QuickBooks, and TurboTax. Their solution was to develop a flexible token taxonomy that transcended individual brand themes.
Nate Baldwin, in his detailed case study, explains that the key to their success was moving away from hard-coded values toward a system of intent. By separating the primitive (e.g., blue-500) from the semantic (e.g., action-primary-background), they created a system that could evolve without breaking legacy products. This approach ensures that if a brand color changes, the developer only needs to update the reference in one place.
Industry Perspectives: The Component Gallery
When in doubt, look at how the industry leaders handle it. The Component Gallery, curated by Iain Bean, acts as a visual dictionary of UI components from real-world design systems. It allows teams to see how different organizations name common elements like accordions, modals, or navigation drawers. It is a vital tool for those who want to align with industry standards rather than reinventing the wheel.
Implications for Feature Adoption
A critical, often overlooked aspect of naming is its direct impact on feature adoption. Erin Gannon, in her insightful guide, "What Do We Call This Thing?," argues that poor adoption is frequently a result of poor naming.
If a user cannot understand what a feature does based on its label, they will not use it.
- The Job-To-Be-Done (JTBD) Approach: Name features based on the value or outcome they provide to the user.
- User-Centric Language: If your users call a process "billing," do not label it "invoicing" simply because it sounds more professional. Use the language of your customer.
Advanced Systems: The Vodafone Taxonomy Map
For complex, multi-brand organizations, the Vodafone UK Variables Taxonomy Map serves as a gold standard. It breaks down the anatomy of a token into a four-level hierarchy:
- Brand: The base values.
- Primitives: The foundational variables.
- Semantics: The functional intent.
- Pages: Context-specific applications.
This structure allows teams to understand exactly where a token is used and what it represents simply by reading its name. It is a scalable, robust framework that effectively manages the chaos of large-scale design systems.
Conclusion: Bridging the Dialects
The primary takeaway for any design or engineering team is that naming is a collaborative act of translation. When designers, developers, and product managers use different dialects, the resulting "translation errors" manifest as bugs, UI inconsistencies, and frustrated users.
By utilizing resources like Onym for product naming, or Romina Kavcic’s Design Token Guide for system architecture, teams can significantly reduce friction.
Final Recommendations for Teams:
- Create a Glossary: Maintain a living document of agreed-upon terms for all components and tokens.
- Audit Regularly: Naming conventions can drift over time. Conduct quarterly audits of your design tokens and class names.
- Prioritize User Testing: When naming features, run A/B tests to see which label results in higher discovery and interaction.
Ultimately, the right name is the one that is understood by everyone. It is the bridge between the internal complexity of your product and the external simplicity expected by your users. Investing in the architecture of your language is, quite simply, an investment in the success of your product.
Editor’s Note: The digital landscape is constantly evolving, and so is our language. We encourage teams to stay curious and continue sharing their naming methodologies. If you are interested in deep-diving into these topics further, keep an eye on our upcoming online workshops, where we frequently host sessions on building scalable design systems and improving product UX.
