What all these design token tools have in common is that they read design token data (i.e. a “single source of truth”) from somewhere (usually a file) and convert the tokens into a variety of output formats.
While each design token tool has slightly different capabilities, ultimately, they all do the same job. They also all use JSON and/or YAML to store design token data. The problem is, they each structure those file very differently.(Note that DSM is web-based and stores its design token data internally. However, it can output it as JSON)
Shopify’s Polaris team stitched together DSM and Theo. They manage colours in DSM (via Sketch + Craft plug-in), but then have scripts that fetch the token data from DSM and feed it into Theo for further conversion.See: https://github.com/Shopify/polaris-tokens/blob/master/.github/CONTRIBUTING.md#editing-design-tokens
--- I made a little Node script that generates a URL to view all colours from DSM / Brand.ai in the EightShapes Contrast Grid tool, to check which pairings have accessible contrast ratios. https://gist.github.com/james-nash/39bd715d57a31c3de4cb96b58ca0d627
What if we had one, universal file format for design tokens? Tools could read that format and directly export it (nothing new) Or, we could convert into another token format and then use existing tools The conversion could be two-way, enabling easy migration between tools Tools could read it and feed it into other tools (e.g. a11y tests) Existing tools could natively export this format Or import it And we could make tools to simply manipulate design token data directly (e.g. merging files, filtering values, combining colours into pairings and gradients, etc.) That’s what Universal Design Tokens aims to achieve!
Standardising around a common file format, could give rise to a vibrant eco-system of little tools and utilities that can be easily stitched together in myriad ways.
We’ve already got wonderful tools for manipulating colours, typographic scale, font pairings, spacing, etc. Imagine if they could all read and write UDT files. They’d become specialised token editor tools we could all use!
In a similar vein, design and prototyping tools could add built-in support to import and export UDT files.
Design tokens can also be useful elsewhere. E.g. to be used within templates for Office documents (Mozilla already did something similar for Photon - it exports colours to a Keynote template). Or for design linting / checking tools like Toybox (https://www.toyboxsystems.com/). That could either be via intermediate tools that read UDT and export something else, or via direct support.Either way, having a common format will make it easier to create and maintain such tools.
3 main tasks
• Write human-readable specs and docs
• Intro / tutorial
• Examples, recipes, FAQs, etc.
• Create schema for validation
• JSON Schema?
• Help tool developers maintain interoperability
• Build reference implementation of parser / serialiser
• Prove that things work
• Potential basis for other tools to use
• Engage with maintainers of Theo, Style Dictionary, etc.
• Do we (continue to) make something new?
• Pro: Can try new things. No politics.
• Con: Reinventing the wheel. Yet another token tool.
• Do we evolve Theo or SD’s format?
• Pro: Probably quicker. Existing user base.
• Con: Who gets to be the basis and why? Would there