🪙 Token metadata enhancements
As the community uses design tokens in more complex ways, they would like to see additional metadata added to their tokens as a way to organize their design decisions in the plugin and in code:
Accessibility scores
Status of a token
Version control information
Creation date
Last updated date
Created by
Last updated by
Custom metadata
Plugin users could sort, filter and group their tokens by these properties if they wish, and engineers could build automated workflow enhancements when the data changes.\
Display Tokens with Broken links to Variables
Problem:
There is currently no efficient way to identify broken links between tokens and their corresponding
styles & variablesin Figma. This issue is critical for teams working on large design systems. The current method requires users to manually review all collections/themes to verify each connection, leading to potential oversight of broken connections and loss of tracking.
Solution:
Introduce a dedicated tab or view that displays all tokens with broken links specifically related to their corresponding variables. Implement a high-level indicator on the collection/theme page that flags broken connections, allowing users to quickly identify issues without needing to check each collection/theme individually.
User suggestion:

🧐 The reality
The DTCG W3C draft has a specification for $extensions which could support this, but Style Dictionary may have a different way to approach this, so that would need to be considered.
💭 How might we...
Introduce additional information to be added to a design token in a way that doesn't clutter the no-code experience for plugin users but allows this powerful information to be available on demand and in code?
💬 Feedback that is valuable
How does this issue impact your day-to-day workflow?
What workarounds do you have?
What additional metadata would improve your workflow?
↔ Related topics
🪙 Add support for Token usage metadata → Jump to post
Log in to comment and vote
Comments2
Luke Finch
Apr 17, 2024
I think metadata is a great idea, however, I don't know if $extensions is the right place for some of the requested datapoints.
One outcome of the spec is to have transferrable tokens between tools and pipelines. Therefore any tool could in theory modify a token as part of its lifecycle.
Given the nature of reverse-domain name notation, it's good manners to keep all of our data under:
$extensions: { studio.tokens: {....} }However, it's also good manners not to write over other people's data.
We could track metadata for things related to only ourselves, but the modified dates etc would be inaccurate.
I think it's worth suggesting the date-related metadata to the DTCG group, which any tool could modify.
Sam - Tokens Studio
Apr 2, 2024
Github Issues
907
1440
2501
2256