A Practical Guide to Naming Systems Across Design and Code
Clear taxonomies for tokens, components, and features eliminate cross-team misalignment and boost adoption.
1The Cross-Functional Dialect Gap
Naming choices often fail by being either too generic to understand or too specific to scale. When designers, developers, and product managers invent separate dialects for the same UI elements, adoption collapses. Standardized naming establishes a shared mental model that bridges interface design, code implementation, and actual user vocabulary.
2Standardizing Code and Color Repositories
Selecting programmatic terms requires moving beyond obvious descriptors into structured linguistic palettes. Curated lexical libraries offer thematic classifications spanning behaviors and relations to name CSS classes and JavaScript functions cleanly. For design palettes, comprehensive databases with over 30,000 distinct names remove subjective guesswork when defining color foundations across systems.
3Structural Rules for Layers and Groups
Effective component and layer nomenclature relies on predictable logic rather than visual descriptions. Javier Cuello notes that solid naming requires short, universally recognized labels divorced from transient visual attributes. Establishing precise conventions for sizes, layers, and groups prevents organizational bloat as file libraries and interface structures expand.
4Multi-Brand Design Token Taxonomies
Enterprises managing diverse portfolios require multi-tiered token hierarchies. Nate Baldwin detailed how Intuit restructured its design token framework across Mailchimp, QuickBooks, TurboTax, and Mint. Their scalable taxonomy transcends single-brand themes, defining clear criteria to decouple core primitives from product-specific contexts and simplify multi-platform distribution across large engineering ecosystems.
5Mapping Enterprise Variable Hierarchies
Vodafone UK built a comprehensive Variables Taxonomy Map to manage multi-brand, multi-theme design systems. Expanding on Nathan Curtis's architectural models, their system divides tokens into four distinct collections: brand, primitives, semantics, and pages. This explicit relational structure enables engineers and designers to instantly infer token usage and intent directly from its name.
6Standardizing Component Vocabularies
Consolidating component labels across fragmented industry standards prevents redundant design patterns. Resources like Iain Bean's Component Gallery document naming patterns across more than 50 standard UI elements, including accordions and hidden utilities. Comparing cross-system aliases ensures teams select standard definitions that external libraries and incoming developers already recognize.
7User-Centric Feature Nomenclature
Low feature adoption frequently stems from naming that fails to communicate functional value. Erin Gannon emphasizes that feature labels must reflect customer jobs-to-be-done rather than internal technical implementations. Interviewing users and directly adopting their natural phrasing ensures new capabilities are quickly discovered, understood, and integrated into regular operational workflows.
8System Governance and Token Inventories
Maintaining scalable systems requires ongoing governance tools like four-level token inventory spreadsheets and structured role matrices. Romina Kavcic's frameworks help teams configure categories, states, and component roles without losing track across themes. Logging naming conflicts into backlog queues steadily eliminates cross-team friction and accelerates cross-functional product execution.
Original article: Smashing Magazine — A Practical Guide to Naming Systems Across Design and Code