Popularised by an article from Nathan Curtis called “Tokens in Design Systems”, the first design tokens seem to have been set up by the UX team of Salesforce for their Lightning design system. It is interesting to note that it is an implementation made by the UX team: the design system is here really thought as a proper product, and the design and development process are really thought as a proper user experience that needs to be designed and improved.
Design tokens are like variables, but they are more than that. They are visual design attributes that are stored, organised, centralised and propagated, with the aim of improving the team communication, the consistency of interfaces and applications, and more globally the maintainability of a system, promoting reuse and collaboration.
#2b7de8 is stored in the entity
blue-base. Decisions are assets that match options with object or “business” tokens. For instance
header-color (object) or
primary-color, (business) could match our
blue-base token. Options define the assets that can be used and decisions define how to apply these options to contexts.
The benefits of this method are numerous. The design tokens improve collaboration by empowering non-developers to engage with code thanks to a more human-readable language ; they facilitate the maintenance with a living documentation and less hardcoded-values in the style files ; just like the components and styleguide approach, they promote the specification of a ”shared vocabulary” around all these visual attributes at the root of every application, …
I took some time to give a more illustrated talk to my teammates at Startup Palace to present them this idea and some experimentations, and I then introduced this tool in a short talk for the Human talks in Nantes
Here are the slides I made to support my presentation. You can also read them directly at thibault.mahe.io/talks/design-tokens/.