Notes from the first roundtable

To make a first step to a wider adoption of design tokens, the W3C Design Tokens Community Group held a roundtable in March.

This meeting had several objectives:

1. Gauge appetite for design tokens standardization
2. Present design tool vendors DTCG’s goals and vision
3. Seek help from vendors to edit and give feedback on parts of the specification

Who was around the table

Here are companies which attended the event: Google (Material Design), Framer, Marvel, zeroheight, Figma, Sketch, Adobe (XD), InVision, Interplay, Knapsack, Arcade, UXPin, Axure, Modulz, Abstract, Zeplin and the representatives of tools such as Style Dictionary and Specify who are also editors on the DTCG.

The good news is that all the vendors are open and willing to adopt standards if it doesn’t limit them or their customers.

Current design tokens adoption by vendors

Adobe (XD)

They have been working hard on design tokens whether it’s for their own internal requirements or for their users. In October 2020, they announced the DSP format which is like “a PDF for design systems allowing you to store agnostic information that can be shared across tools”.

Figma

Design tokens come up a lot from their customers. They embrace that organizations work differently and want to keep the free-form creativity provided by their design environment. While they appreciate standardization, it has to allow the various ways customers work.

Framer

Currently, users can use design tokens in Framer using code-based techniques (React/JavaScript).

They are working on a new solution for tokens that scales fully across their customer base. The improved token system will not only work within the tool, but can help bridge to production as well.

They see standardization of design tokens as an opportunity to avoid limiting themselves or their customers in the future.

Google Material Design

Design tokens matter to them as they’re creating so many applications for various devices and applications. They need the spec to work across different platforms.

Interplay

They want their customers to be able to export their design tokens to design tools. They already have their own design token structure.

Marvel

Their customer needs about design tokens are varied. This is why they want their customers to remain free when managing design tokens. They are working on an API layer for design tokens acting as a layer between designers and developers.

Sketch

They provide Sketch libraries helping their customers manage their design tokens and components. In addition they also have a plugin environment.

UXPin

They provide libraries allowing their customers to store their own design tokens and documentation.

Our industry needs a standard for design tokens

Every vendor agreed on the fact that the digital design and development industry would benefit from a standardized technical approach. This future standard should be flexible enough for vendors to build upon without limitations.

Standardizing design and development tools: easier said than done

We asked the following question: “Do you agree a standard between design tools and codebases would make design and development collaboration cheaper, faster, and more integrated for customers?”. Some vendors agreed and some didn’t. It all comes down to the future liberty vendors will benefit from the standard. Every tool is different and it may not be possible to align every tool with each other. The DTCG will follow its research on the subject.

Next steps

1. One of the next steps was to get answers from vendors on the questions we didn’t have time to get to:
   • Do you see your tool’s primary use case as consuming design tokens, outputting design tokens, managing design tokens…?
   • To naming concepts such as data types, should the specification follow existing conventions such as the ones in CSS or stay away from it?
   • For example: how would you feel if it used the familiar “line-height” vs the more typographically-accurate “leading”, or another name like “line spacing”?
   • Should this specification aim to standardize some naming and nesting conventions, or entirely leave that to users and tools?
   • For example: “colors”/“typography”/“spacing” top-level categories, names such as “primary brand”, “color-<range #>” for palettes, …
2. We sent vendors our first editor’s draft
3. We will conduct focus groups with some vendors on precise topics from the spec

This roundtable sparked lots of great debate, and we thank everyone who could make it for responding to our call.