Skip to toolbar

Community & Business Groups

Design Tokens Community Group

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.

design-tokens/community-group
Group's public email, repo and wiki activity over time

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.

Drafts / licensing info

Date Name
Design Tokens Format Module

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Call to implement the Second Editors’ Draft and share feedback

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):

  • All format properties are now prefixed with $, as in: type$type
  • The font type has been renamed to fontFamily
  • The cubic-bezier type has been renamed to cubicBezier
  • User-defined composite types and the associated typedef type have been removed

Additions

Community feedback around efficiency and commonly used patterns informed these additions:

  • New fontWeight type
  • 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.

Call to participate in Color and Animation format survey

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!

Call to read the First Public Editor’s Draft and share feedback

Over the past several months, the team collaborated with multiple design tool vendors to draft the format module of the Design Tokens specification.

We’re now inviting everyone in the community to read the First Public Editor’s Draft and join the conversation on GitHub.

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?

  1. 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.
  2. 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.
  3. 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.

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.

First Editor’s Draft shared with design tooling vendors

Yesterday, we reached an exciting milestone and shared the First Editor’s Draft of the Design Tokens specification with design tooling vendors.

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!

Kaelig

Upcoming event: design tool vendor roundtable

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.

  1. Proposed resolution: the digital design and development industry would benefit from a standardized technical approach to sharing stylistic properties across tools and codebases.
  2. Proposed resolution: a standardized approach to styling across design tools and codebases would make design/development collaboration cheaper, faster, more integrated for customers.
  3. 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…?
  4. Open question: do you see your tool’s primary use case as consuming design tokens, outputting design tokens, managing design tokens…?
  5. Open question: what, if anything, would be a non-starter or hard requirement for supporting a design token specification (legally, technically…)?
  6. 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, …
  7. 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.

Status update (February 2021)

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!

Call for specification editors

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.

Looking forward to hearing from y’all!

@jina & @kaelig
Follow the discussion on GitHub

Actions required for contributors: join the group and watch the repository

(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.

[Action required 1]
Join the community group (it’s free, and doesn’t require a W3C membership).
Instructions: w3.org/community/design-tokens/2019/07/31/call-for-participation-in-design-tokens-community-group

[Action required 2]
Watch the repository to be notified of all conversations:

  1. Go to design-tokens/community-group
  2. In the top right-hand corner (on large screens), click “Watch”
  3. 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.

For more information, read the full charter .

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.

If you have any questions about this process and the community group, please ask it publicly in the dedicated GitHub issue or get in touch with me directly: kaelig@deloumeau.fr.

Thank you!

Kaelig Deloumeau-Prigent, Co-chair