Public

There are many benefits of choosing a formal name for your design system: A helpful shorthand – A design system’s name is its brand name, and that name becomes a shorthand that encapsulates and embodies what the whole effort is about. Mitigates confusion – many organizations have different permutations and generations of design systems floating around. Having a name that is distinct from “our company’s design system” can really helps clarify things. A design system called Splat allows people to say “Splat’s design tokens”, “Splat’s accordion”, and so on. Creates a global namespace – Having a distinct global namespace for a design system is really important: it prevents collisions with non-design system code, creates a useful web component namespace, unlocks the ability to measure adoption, and more. So if the name is Splat, you could define splat-card, splat-button, splat-accordion and so on in CSS and code. Helps with marketing efforts – a brand name for the design system helps disseminate it around the organization. It can be helpful, exciting, and fun to have a real product name floating around. We’ve had clients create Christmas ornaments, t-shirts, mugs, and other swag.

People have a long history of taking elements/components that were intended for specific use cases, and then stressing them to their limit to fit their use case.

What I mean is that "design tokens" are a language for communicating intent between disparate parts of a system.

Calling it “design tokens” is useful because it makes clear what the purpose of the constructed language is: to communicate information that informs the design system.

By definition, that’s complex and nuanced work. It’s an attempt to make explicit and dependable something that has (in most publishing systems) been implicit and inconsistent. It faces all the challenges of language.