Using design tokens to promote collaboration and maintainability of a design system

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.

• ”Stored” means that the design tokens are like variables that aren’t burried in stylesheets or less / sass files. They are abstracted in a different, more agnostic, data format, like json or yml.
• ”Organised” means that the way we can manage design tokens allows to define some rules and good patterns. In his original article, Nathan Curtis promotes the idea that tokens can be managed in “options” and “decisions”. Options are possibilities given by the designer to build a visual identity; they ”take the mystery out of obscure values”. For instance #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.
• ”Centralised” means that these tokens are at the root of the design system, i.e. they are at the root of the styleguide (in the folder architecture) and of the process (anyone can define and edit them). Moreover, since they are stored in a more legible and editable format, they become easier to use for non-developers.
• ”Propagated” means that the tokens are part of a process in which they are transformed and exported in various formats, such as Sass variables, Less variables, Json, Xml, etc. This way, they can be used by different products, applications and technologies, fostering maintainability and consistency accross all these separated experiences.

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/.