Best Practices For Naming Design Tokens, Components And Variables

Naming is hard but crucial — Names should be clear, consistent, and scalable across teams and projects. The article emphasizes that the struggle with naming (too generic, too specific, hard to remember) is real, and good naming practices alleviate friction.

• Principles of good names
   • Logical structure — there should be a pattern or hierarchy in your names.
   • Short yet meaningful — avoid overly verbose names, but don’t sacrifice clarity.
   • Shared vocabulary — the team must understand and agree on the terms used.
   • Avoid visual references in names — names should reflect meaning and intent, not appearance (so the name still makes sense if the UI changes).

• Design token naming
   A well-defined taxonomy is vital. Use interactive tools (like the cited Design Tokens Naming Playbook) and source-of-truth systems (spreadsheets, plugins) to maintain consistency.

• Color naming
   Name colors with a combination of semantic names and numeric scales (e.g. “blue-500”) so that names are both descriptive and scalable. This helps avoid ambiguity as the design system grows.

• Component naming & conventions
   Look at naming conventions in existing design systems; considering community conventions helps avoid reinventing the wheel and improves understandability across multiple systems.

• Systems & tooling to support naming consistency
   Use taxonomy maps, inventories, and tools integrated with design systems (e.g. Figma plugins, synchronized spreadsheets) to keep naming consistent even as the system evolves.

• Scalability and flexibility
   Your naming system must anticipate growth (new components, themes, brands). A flexible taxonomy helps you avoid brittle names that break or need massive refactoring later.