The Design Tokens Community Group's goal is to provide standards upon which products and design tools can rely for sharing stylistic pieces of a design system at scale.
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Over the past several months, the team has been collecting feedback from the community on the First Public Editor’s Draft. Based on that feedback and community support, we’re publishing the Second Editor’s Draft.
We invite everyone in the community to review this latest Editor’s Draft and join the conversation on GitHub as we finalize the remaining details towards publishing a Final Report.
For the first time, we also invite tool makers to start implementing the format with this milestone and share feedback with our team (GitHub preferred, or email kaelig@deloumeau.fr to discuss other ways to share privately).
Thanks to everyone in the community for your participation. We can’t wait to build the future of design tokens together!
What’s new?
Here is an overview of what has changed in this Second Editor’s Draft:
Breaking changes
These breaking changes are the most significant updates in this second draft, and will be of most interest to tool makers who were already relying on the first public draft (such as the Figma Tokens plugin):
Additional pre-defined composite types, supporting a wider range of common composite token needs: strokeStyle, border, transition, shadow, gradient, and typography
Updates to groups, improving readability and consistency
A few other changes were made throughout the draft for clarity and grammatical errors.
We need your feedback
The Second Editor’s Draft is the “last call” for meaningful changes before the first Final Draft.
Post new issues or join in on the GitHub conversations about any concerns, additions, or other changes you’d like to discuss.
The DTCG editors request the community’s feedback on the specifics of the Color and Animation modules. We invite the community to fill out this short survey by February 21st 2022, and join the conversation on GitHub.
Thanks to everyone in the community for your participation. We can’t wait to build the future of design tokens together!
Thanks to everyone in the community and to all vendors who helped in reaching this milestone. We can’t wait to keep working with you and build the future of design tokens together!
What’s next?
Editors will compile community feedback and work to reach a consensus on every issue that’s been raised. Expect the draft to change a lot during this step.
Once critical issues are solved, we’ll publish a First Working Draft. Expect rare edits to normative sections of the Working Draft. At this stage, the specification can be used to build implementations. We’ll be collecting more feedback from vendors, tool developers, plugins/extension developers.
Once multiple vendors have implementations that follow the Working Draft, we’ll move to Final Specification.
During steps 2 and 3, the W3C will review the reports to exclude any risk of intellectual property infringement.
In parallel, we’ll work on other modules that depend on the Format Module, such as Colors, Motion, Typography.
Present design tool vendors DTCG’s goals and vision
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
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, …
— Design Tokens Community Group (@DesignTokens) April 17, 2021
Screenshot of the first page of the First Editor’s Draft
The draft will be public soon. For now, there are critical questions that must be addressed with implementers (design tooling vendors). Once we have better clarity on these points, we’ll start collecting feedback from the broader community.
Here’s the message we sent to Google (Material Design), Framer, Marvel, ZeroHeight, Axure, Figma, Sketch, Adobe (XD), Interplay, Knapsack, Arcade, UXPin, Specify, Zeplin, InVision, Abstract, Zeplin, Modulz, and a few members of the CSS Working Group:
Everyone,
We’re excited to share the First Editor’s Draft of the Design Tokens specification.
You and your teams are the first to access this document. Share it freely with your colleagues, but wait until it reaches “First Public Working Draft” status to share it publicly.
Using your feedback and suggestions, we’ll make edits to the Editor’s Draft, which, I expect, will go through a few iterations. Once we’ve settled the most critical questions, we’ll release the First Public Working Draft. For areas that need further consideration, we’ll set up focus group workshops.
We appreciate feedback on all sections of the draft, and we added “Request for comments” blocks to guide your attention on areas we particularly need to disambiguate.
Please leave your comments, questions, and suggestions in the Google Doc, or email Jina and me (kaelig@deloumeau.fr, sushiandrobots at gmail dot com) if you prefer providing your thoughts that way.
Later, when the document reaches “First Public Working Draft” status, we’ll use GitHub issues to discuss areas of the spec that need disambiguation.
Many thanks, and let me know if you have any questions!
Design tool vendors are invited to participate in our first roundtable. This 2-hour event is open to companies who build digital product design apps and platforms, as well as bodies such as the CSS working group and Google, who are influencing the state of product design at a large scale.
Date: March 24th, 2020 from 9:30 AM to 11:30 AM (Pacific Time)
Objectives
Get to know each other, put faces on names
Gauge appetite for design tokens standardization
Align on core principles driving standardization efforts
Gather use-cases the DTCG should prioritize (identify 5 to 10 user needs shared by vendors, extract the most common ones)
Seek help from vendors to edit and give feedback on parts of the specification
Next step: workshops with editors and vendors on focused areas such as color data types, format, syntax…
Hear diverse opinions from the vendor community
Vendors: you’ll hear where the rest of the industry is headed, and get an opportunity to ask questions to DTCG chairs and editors
Agenda
Introductions
DTCG presentation (Jina and Kaelig)
Vendor presentations
Roundtable discussion
Introductions
Each participant presents themselves using this format:
Name and pronouns
Current position & employer, and relevant past experience
What you’re most excited about when it comes to design tooling
DTCG presentation
Co-chairs Jina and Kaelig will set the context by sharing a short presentation:
Short history of design tokens, and why the DTCG?
Quick description of the DTCG’s processes
Current state of the format specification draft
Future of design tokens
Vendor presentations
Each vendor has 5 minutes to talk about the state of design tokens in their product, and will take questions from the rest of the roundtable (5 min). Free form, at your discretion (speech, presentation, demo… no pitches, please).
It’s okay to play a recording of your presentation if you’d prefer to pre-record it, or if you can’t make it to this meeting.
Examples of topics the community group and other vendors would be interested in:
What features in your product currently resemble design tokens (inspect/code panels, shared styles/libraries, import/export color palettes…)?
What’s the appetite (if any) from your customers for design tokens in your product?
Have you thought about design tokens being part of your product? Is it already on your roadmap? If so, what areas of your product would benefit the most from design tokens? Can you share concept designs with the rest of the group?
Roundtable discussion
Resolution proposals are voted upon by attendees. They are assumptions we believe to be true and will help the DTCG move forward with support from the vendors. If a proposed resolution isn’t adopted, it will result in further discussions to rephrase it or reassess its relevance.
Attendees are expected to prepare to share opinions and to ask questions or voice their disagreement when they have reservations on a topic.
Proposed resolution: the digital design and development industry would benefit from a standardized technical approach to sharing stylistic properties across tools and codebases.
Proposed resolution: a standardized approach to styling across design tools and codebases would make design/development collaboration cheaper, faster, more integrated for customers.
Open question: what’s the smallest set of functionality that the original spec draft should cover to make it implementable and useful to your users? Think: base format & grammar, composite tokens, colors, typography…?
Open question: do you see your tool’s primary use case as consuming design tokens, outputting design tokens, managing design tokens…?
Open question: what, if anything, would be a non-starter or hard requirement for supporting a design token specification (legally, technically…)?
Open question: 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, …
Open question: 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”?
A report from this roundtable will be posted here or on GitHub in the weeks following the event.
Current list of companies that have been contacted to attend, in no particular order: Google (Material Design), Framer, Marvel, ZeroHeight, Axure, Figma, Sketch, Adobe (XD), Interplay, Knapsack, Arcade, UXPin, and the representatives of tools such as Style Dictionary and Specify who are also editors on the DTCG.
Hello, world! This is the first monthly Design Tokens Community Group (DTCG) update, where we’ll publish a summary of our activities and progress. If you have questions, comments, or ideas, please get in touch with us on GitHub, Twitter or by leaving a comment in this blog.
Draft specification
After months of research and discussions, the core team is now drafting the format specification. We’ll share it and request feedback with a small set of invited experts and design tool vendors at first, and open it up to the wider community shortly after. Watch this space!
Glossary
As design systems folks are fond of saying: “Naming is hard”! What, exactly, is a “design token”? Is an “alias” the same thing as a “reference”? What do we mean by the “type” of a token? To answer these questions and more, the DTCG has begun writing a glossary of terms.
The initial motivation was for the core team to agree upon and document some of the terminology that will be used in the specification, but we realized this will be a useful resource for the wider community too. Therefore, we are planning to publish our glossary on the designtokens.org website once it’s ready.
Vendor roundtable meeting
Finally, the DTCG is organizing a meeting with representatives from design tool makers around mid March. This will be an opportunity for us all to get to know each other, clarify key use-cases and hopefully get some of the vendors to contribute to our format specification.
Look out for news from that meeting in our future updates!
Dear group members, today we’re excited to start our first call for editors 🎉
One of the DTCG’s main goals is to produce a specification.
The specification is broken into multiple modules:
Format (the language and its grammar)
Colors
Spacing
Easing
(more to come!)
We need 2 to 3 editors per module, ideally representing various interests: design tool makers, design system creators and maintainers, users of design systems, as well as design token tool makers.
Read the full call for editors (in Google Docs) to learn more and apply to become an editor.
(the content below was also sent as an email to everyone who showed interest in the design tokens community group and posted as a GitHub issue)
Hi,
You’re receiving this message because you’ve shown an interest in the Design Tokens W3C Community Group. Its goal is to provide standards upon which products and design tools can rely for sharing stylistic pieces of a design system at scale.
To make substantive contributions to specifications, you must either join the Design Tokens W3C Community Group or make a non-member patent licensing commitment.
In the top right-hand corner (on large screens), click “Watch”
Select the “Watching” option
As per the group’s charter, contributions happen in GitHub and can be made in the form of pull requests, issues, or comments:
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All documents in the repository are licensed by contributors under the W3C Document License.
Please also read the code of conduct. It will be enforced with a zero-tolerance policy to ensure the community group is an open and welcoming environment.
Next steps (choosing a chair and specification editors, workshops, meet-and-greet) will be communicated soon on the GitHub repository.
design-tokens/community-group
