Figma’s design conference Config just ended and one of the biggest announcements is the introduction of Variables. The reaction from the community is a mix of emotions. While many people were expecting Design Tokens, some can see the clear benefits of Variables while others are skeptical about perceived defiance to existing specifications. We’ll explore the current state of specifications for Design Tokens across the community and how Variables come into play.
Token specifications today
These are a few popular or relevant specifications that aim to describe the shape of a Design Token. While I haven’t completed an exhaustive search through existing systems with their own formats, the following examples will be enough to illustrate the current state of affairs.
Design Tokens Community Group
The Design Tokens Community Group (DTCG) is a collection of Design Tokens stakeholders from around the community representing design and development tools along with experts with working knowledge and experience in maintaining token libraries. The group has made some strides in a specification but it is very far from complete. The expectation is that all tools should adhere to this specification so that our representation of Design Tokens can be shared across tools. If there are deviations, a tool may skip a definition or fail. Here’s a basic example of a Design Token meant to describe a token color-red-500.
{
"colors": {
"color-red-500": {
"$type": "color",
"$value": "#f00",
}
}
}This is the core of the DTCG specification; a nested object with unique names. At the lowest nesting there should exist $type and $value keys; where the $ denotes a special key that is meaningful for tools to read. In the example, the tool should know that the #f00 is a color value and handle it accordingly. There are a few other keys and other more complex configurations, but this is the foundation that everyone is expected to follow.
Tokens Studio
Tokens Studio (built from a plugin project called Figma Tokens) has had a longer history of use (Jun 2020) than the first agreement provided by the DTCG (Apr 2021). This was to fill needs that were not solved within Figma at the time. Therefore, their specification is slightly different.
{
"colors": {
"color-red-500": {
"type": "color",
"value": "#f00"
}
}
}Note that the above is for a multi-file storage configuration. There are special keys expected at the first nesting level when using single-file storage. Also, note the absence of $ from the type and value which is not to DTCG specification today. Mike Kamminga, Tokens Studio CEO, says:
We have been transitioning to fully support the DTCG proposal.
Importantly, to support more complex customer needs, Tokens Studio has included additional features that the DTGC specification has not yet provided. Continued from the previous quote:
…we do fill some gaps where the proposed spec doesn’t provide solutions yet.
An example of filling gaps comes in the form of token resolvers which aim to describe complex relationships and conditionals which compute token values. While this has been suggested within the DTCG discussions, there are no official recommendations.
Specify
Specify is a design token management tool that has been around before the DTCG and has had integrations with Sketch before Figma. A few weeks ago, they announced the Specify Design Token Format (SDTF). An excerpt from their example is below:
{
"colors": {
"color-red-500": {
"$type": "color",
"$value": {
"default": {
"model": "hex",
"hex": "#f00",
"alpha": 1,
}
}
}
}
}The standout part of the above is the $value which is more descriptive than the others, containing more information about the value than only the string. As of today, this does not follow the DTCG specification but perhaps that’s by design. Nicolas André, Specify Senior Software Engineer, says:
The SDTF is not a file. The SDTF is designed to be a transport format between APIs that would eventually being configured by humans. To interact with it, we’ll use dedicated APIs lowering the underlaying complexity.
So the expectation here is that there are additional external systems that exist between APIs that expect this format.
Why not Design Tokens?
Jacob Miller, Figma Product Manager, says:
Our reasons for naming it variables was primarily to align with development. Variables, much like css variables, is not just for design tokens, it’s also for conditional logic, string translations, etc.
The important takeaway here is that Variables can be used to describe our idea of Design Tokens but also to support additional needs which will most likely exist outside Design Token expectations. A clear example of this is content substitutions for localization. Design Tokens were not created to support this foundationally but Variables, uniquely defined by Figma, can.
For reference here is an example of a Figma Variable:
{
"id": "<FIGMA_INTERNAL_VARIABLE_ID>",
"name": "color-red-500",
"resolvedType": "COLOR",
"valuesByMode": {
"<FIGMA_INTERNAL_MODE_ID>": "#f00"
}
}This is not a Design Token but Figma’s proprietary format meant for use within the Figma ecosystem. Based on the official plugin built to transform Variables into Design Tokens, the valuesByMode will store several values by a unique identifier that relates to a mode. The mode could be light, dark, dense, Spanish, or many others and the value for this Variable can differ depending on the mode.
A deliberate choice
Figma has intelligently chosen the word “Variable” to opt out of following the specification to support its product features but also offers the import/export of the DTCG specification where appropriate against its Variables. I believe this is the correct direction as the DTCG learns from existing patterns. This allows Figma to go far beyond the responsibility of the specification in ways Design Tokens were never meant to be used.
You could argue that Token Studio and Specify are also behaving in the same way. However, I fear their current offerings are confusing when compared with the DTCG. Again, Figma made a conscious decision to create a unique ecosystem to allow for new features to be built; Variables are not Design Tokens. This is a subtle but important distinction as the other products create their own variations on top of an incomplete specification using conflicting methodologies. In other words, one cannot use a fully featured Tokens Studio file within Specify due to the incompatibility between specifications.
I believe the root of the problem is using the name Design Token for experimental approaches while a group aims to define what it means to be a Design Token. These other formats do not follow the specification in small and large ways and are therefore not accurate in describing Design Tokens as we expect them to be used in the community universally. Rebranding these novel approaches as something else for future features (as Figma has done) would make the expectations and responsibilities of Design Tokens more understandable to the community moving forward.
I have empathy for the pioneers like Tokens Studio and Specify; existing before the specification makes this exceptionally challenging for them, borderline unfair. What Specify has done is a good start; creating a branded “flavor” of Design Tokens with the SDTF. I’d recommend Token Studio do something similar such as TSTF. In this way, it can be perceived that these approaches are Design Token adjacent instead of wholly accurate to the community specification.
Let me be clear, I support the advancements that all of these companies are providing for the Design Tokens community. They are heavily influencing the direction of the specification and we could not be where we are today without this work. I am being critical of what a Design Token is expected to be as it currently depends on where you get your tokens from. I have confidence that alignment will come, it’s simply a noisy time to get started.