7 ms·

Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1] There's a whol

by kaelig 2y ago

Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1] There's a whole movement bringing DevOps and SRE thinking to design/UX, essentially working on design infrastructure. Design Tokens are a part of it. Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. 1: https://tr.designtokens.org/format/ https://tr.designtokens.org/format/

spankalee 2y ago
Why does the format use $-prefixed keys? That's pretty weird as far as JSON schemas go.
- Jarwain 2y ago
  Not just weird, it kinda overlaps with json schema builtins like $schema, $ref, $id, etc
  - deleted 2y ago
    [deleted]
- kaelig 2y ago
  The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions https://tr.designtokens.org/format/#character-restrictions As for the "pretty weird" aspect — it's definitely uncommon but it's been seen before: the $ prefix is also used by the JSON Reference ($ref): https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01.html https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01... — and just in case, we ran this syntax past Ben Hutton (inventor of JSON Schema) to ensure we weren't doing anything silly.
  - spankalee 2y ago
    You can usually do this by only being additive with the spec, and by never mixing user-defined keys and spec-defined keys in the same object. I've only ever seen $ used before with meta properties that work across all schemas like the $ref you mentioned and $schema.
    - kaelig 2y ago
      There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience. That said, there definitely are other valid ways to solve it.
AdieuToLogic 2y ago
> Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques? In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]? 0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sektion=0&manpath=FreeBSD+14.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sekti... 1 - https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=0&manpath=FreeBSD+14.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sekt...
- kaelig 2y ago
  It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc. At a certain scale, design and brand teams need infrastructure to drive change. These teams rarely have sufficient engineering headcount (if any) to build such tooling and delivery pipelines all the way to the user. Having interoperable formats brings alignment across design and engineering toolchains. The industry needs this methodology to be baked in, rather than requiring folks to build their own tooling.
  - starbugs 2y ago
    > At a certain scale, design and brand teams need infrastructure to drive change What does this mean? Do you have a concrete example of where this actually solves a real problem? And what problem would that be?
    - kaelig 2y ago
      Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mode across an entire suite of products, or perhaps a brand refresh. Having a single source of truth and tooling that supports it end to end from design to engineering helps roll out changes fast and on brand. In turn, it's good for the user! I know a lot of folks here may come from a more backend background so it may help to think of it as: a way to unlock continuous delivery for your design decisions.
anentropic 2y ago
"isn't it just... variables?" I guess this was my thought - a language/framework-agnostic format for a bunch of variables, but also with some opinion towards how they should be structured (option/decision/component layers) ? And then standardising it provides opportunities for interop between tools and multiple frameworks etc
- kaelig 2y ago
  Yes to everything you say, except for "option/decision/component" as that's up to the users. The spec is acting just like how CSS doesn't tell you how to name and nest classes.
  - rendaw 2y ago
    Why call it tokens instead of variables?
    - kaelig 2y ago
      A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term. I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!
    - meiraleal 2y ago
      because they are constants, not really variables?
      - seanhunter 2y ago
        Why not call them constants then? Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".
        rendaw 2y ago
        Yeah... auth tokens, resource tokens, rate limiting tokens, monetary tokens, LLM tokens, parser tokens, etc... you might as well name it "thing". It's about as bad as "node".
et1337 2y ago
Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? And if that’s not the goal, what is the goal?
- kaelig 2y ago
  > Is the goal to be able to change a design token and see that change reflected across all your various UIs? That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a PR for example) > How do you ensure people remember to use the design token instead of hardcoding the value? A combination of great docs, education (onboarding, training), autocomplete, and linting. In design tools, it's baked in to the UI so adoption is less of a problem. > Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? Yes, and that's where visual regression testing comes in and proves valuable to not just developers, but also designers.
- mcrider 2y ago
  For us the killer feature is being able to build the UI once with design tokens and then transform it radically into different themes. In our case the themes serve different brands (of the media company I work for) but more commonly this is a great way to build out light and dark modes. Our tokens are integrated into the designer’s tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
  - bung 2y ago
    > Our tokens are integrated into the designer’s tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers. Like did you integrate into figma, or write a gui for them, or something else?
seanwilson 2y ago
Can you explain the challenges in standardizing this? I don't mean to say it's simple, but curious which parts were easy to standardize and which part are most contentious. I appreciate the standardization efforts here so thanks! So I've been working on an accessible color palette creation tool (https://inclusivecolors.com/ https://inclusivecolors.com/) and wanted to add export formats that were easy to import into other tools. For Figma, amazingly there doesn't seem to be any official/standard way to import variables yet, and instead lots of semi working/broken/abandoned import plugins that support different formats. I ended up adding DTCG, Style Dictionary, and CSS export so the user had some options to try different Figma plugins. It would have been great if there was a single well supported format that was reliable to use here, instead of having to code several export formats that are all roughly the same. Do you know if Figma will adopt DTCG?
mrr500 2y ago
The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?
jastuk 2y ago
I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now. I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?
- kaelig 2y ago
  It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild. The main areas that need work for us to publish a "V1" are: - colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years) - "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.
noworriesnate 2y ago
Isn't the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?
- kaelig 2y ago
  Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is expressed separately. We also need to provide ways for folks to codify dark mode / light mode / high contrast values. Another example is what we call "aliases" or "references": a token can reference another one. Their resolution process needs to be specified (as in: when exactly does an alias get resolved in the lifecycle, and how tools must process them, whether it's okay to rasterize them in the CSS/XML/JS/.. output, etc). Note that we intend to provide a JSON schema, and the community has already published a few TypeScript type definitions, linting tools, and build tools based on the spec. > some are pixels or rem or whatever The 'or whatever' part is what we're trying to tame. For example an Android app may need to consume 'dp' values, web 'rem', iOS 'pt'... There are tons more examples where platforms differ in how they would express dimensions, typography, color... The spec provides a way to encode the source tokens, and then translation tools handle the conversion to platform-specific values.
motorest 2y ago
> Ask me anything (...) Can you explain what problem you are trying to solve, and how do you think is the best way to solve it? The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.
- kaelig 2y ago
  A few members and myself have commented to explain in various ways what we're solving. This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury. The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.
  - motorest 2y ago
    I'm sorry, you wrote words but they don't say anything. They sound like machine-generated nonsense. Can you actually provide a concrete example of a concrete problem you want to solve with the token-based UI initiative? Write your answer following the STAR format, and leave the buzzword bingo out. If you cannot explain your problem then this is a very clear tell that it might not exist at all.
    - kaelig 2y ago
      > They sound like machine-generated nonsense. Fair! Perhaps I should have used an LLM to de-bullshitify my message... Let's walk through a common scenario: Design tool A has brand colors coded in hexadecimal, those have no name, they're just hex values. Design tool B has colors named in CamelCase, values in HSL. Codebases A, B, C have colors in RGB, named the same as in Design Tool B. Codebase D has colors in Hex8, with their own naming convention. 100s of developers copy/paste values from old and new designs over the span of several years. Codebases now have 50 shades of the "primary blue" scattered around. Now user experience feels disjointed at best, confusing and hostile at worst. Engineering design collaboration is tough as no two tools and teams speak the same "design language". Say a team wants to implement a new feature across multiple codebases where styling and naming are all different. Lacks of re-use and poor communication leads to entropy, which leads to poor quality and slower delivery. Design tokens are the interoperable layer that help define a common language across people and tools and improve what I described above. (for those familiar with DDD, there are a lot of similarities) The spec itself is baking this into the entire toolchain so it's available to teams by default, without requiring as much custom tooling. PS: the scenario above may seem extreme to some, but it's _extremely_ common at medium to large companies with no established design/engineering processes.

by kaelig 2y ago

spankalee 2y ago

Why does the format use $-prefixed keys? That's pretty weird as far as JSON schemas go.

Jarwain 2y ago
Not just weird, it kinda overlaps with json schema builtins like $schema, $ref, $id, etc
- deleted 2y ago
  [deleted]
kaelig 2y ago
The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions https://tr.designtokens.org/format/#character-restrictions As for the "pretty weird" aspect — it's definitely uncommon but it's been seen before: the $ prefix is also used by the JSON Reference ($ref): https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01.html https://www.ietf.org/archive/id/draft-pbryan-zyp-json-ref-01... — and just in case, we ran this syntax past Ben Hutton (inventor of JSON Schema) to ensure we weren't doing anything silly.
- spankalee 2y ago
  You can usually do this by only being additive with the spec, and by never mixing user-defined keys and spec-defined keys in the same object. I've only ever seen $ used before with meta properties that work across all schemas like the $ref you mentioned and $schema.
  - kaelig 2y ago
    There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience. That said, there definitely are other valid ways to solve it.

AdieuToLogic 2y ago

> Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques? In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]? 0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sektion=0&manpath=FreeBSD+14.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sekti... 1 - https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sektion=0&manpath=FreeBSD+14.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sekt...

kaelig 2y ago
It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc. At a certain scale, design and brand teams need infrastructure to drive change. These teams rarely have sufficient engineering headcount (if any) to build such tooling and delivery pipelines all the way to the user. Having interoperable formats brings alignment across design and engineering toolchains. The industry needs this methodology to be baked in, rather than requiring folks to build their own tooling.
- starbugs 2y ago
  > At a certain scale, design and brand teams need infrastructure to drive change What does this mean? Do you have a concrete example of where this actually solves a real problem? And what problem would that be?
  - kaelig 2y ago
    Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mode across an entire suite of products, or perhaps a brand refresh. Having a single source of truth and tooling that supports it end to end from design to engineering helps roll out changes fast and on brand. In turn, it's good for the user! I know a lot of folks here may come from a more backend background so it may help to think of it as: a way to unlock continuous delivery for your design decisions.

anentropic 2y ago

"isn't it just... variables?" I guess this was my thought - a language/framework-agnostic format for a bunch of variables, but also with some opinion towards how they should be structured (option/decision/component layers) ? And then standardising it provides opportunities for interop between tools and multiple frameworks etc

kaelig 2y ago
Yes to everything you say, except for "option/decision/component" as that's up to the users. The spec is acting just like how CSS doesn't tell you how to name and nest classes.
- rendaw 2y ago
  Why call it tokens instead of variables?
  - kaelig 2y ago
    A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term. I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!
  - meiraleal 2y ago
    because they are constants, not really variables?
    - seanhunter 2y ago
      Why not call them constants then? Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".
      - rendaw 2y ago
        Yeah... auth tokens, resource tokens, rate limiting tokens, monetary tokens, LLM tokens, parser tokens, etc... you might as well name it "thing". It's about as bad as "node".

et1337 2y ago

Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? And if that’s not the goal, what is the goal?

kaelig 2y ago
> Is the goal to be able to change a design token and see that change reflected across all your various UIs? That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a PR for example) > How do you ensure people remember to use the design token instead of hardcoding the value? A combination of great docs, education (onboarding, training), autocomplete, and linting. In design tools, it's baked in to the UI so adoption is less of a problem. > Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? Yes, and that's where visual regression testing comes in and proves valuable to not just developers, but also designers.
mcrider 2y ago
For us the killer feature is being able to build the UI once with design tokens and then transform it radically into different themes. In our case the themes serve different brands (of the media company I work for) but more commonly this is a great way to build out light and dark modes. Our tokens are integrated into the designer’s tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.
- bung 2y ago
  > Our tokens are integrated into the designer’s tooling and we have a build pipeline that allows them to update the frontend with minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers. Like did you integrate into figma, or write a gui for them, or something else?

seanwilson 2y ago

Can you explain the challenges in standardizing this? I don't mean to say it's simple, but curious which parts were easy to standardize and which part are most contentious. I appreciate the standardization efforts here so thanks! So I've been working on an accessible color palette creation tool (https://inclusivecolors.com/ https://inclusivecolors.com/) and wanted to add export formats that were easy to import into other tools. For Figma, amazingly there doesn't seem to be any official/standard way to import variables yet, and instead lots of semi working/broken/abandoned import plugins that support different formats. I ended up adding DTCG, Style Dictionary, and CSS export so the user had some options to try different Figma plugins. It would have been great if there was a single well supported format that was reliable to use here, instead of having to code several export formats that are all roughly the same. Do you know if Figma will adopt DTCG?

mrr500 2y ago

The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?

jastuk 2y ago

I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now. I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?

kaelig 2y ago
It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild. The main areas that need work for us to publish a "V1" are: - colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years) - "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.

noworriesnate 2y ago

Isn't the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?

kaelig 2y ago
Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is expressed separately. We also need to provide ways for folks to codify dark mode / light mode / high contrast values. Another example is what we call "aliases" or "references": a token can reference another one. Their resolution process needs to be specified (as in: when exactly does an alias get resolved in the lifecycle, and how tools must process them, whether it's okay to rasterize them in the CSS/XML/JS/.. output, etc). Note that we intend to provide a JSON schema, and the community has already published a few TypeScript type definitions, linting tools, and build tools based on the spec. > some are pixels or rem or whatever The 'or whatever' part is what we're trying to tame. For example an Android app may need to consume 'dp' values, web 'rem', iOS 'pt'... There are tons more examples where platforms differ in how they would express dimensions, typography, color... The spec provides a way to encode the source tokens, and then translation tools handle the conversion to platform-specific values.

motorest 2y ago

> Ask me anything (...) Can you explain what problem you are trying to solve, and how do you think is the best way to solve it? The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.

kaelig 2y ago
A few members and myself have commented to explain in various ways what we're solving. This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury. The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.
- motorest 2y ago
  I'm sorry, you wrote words but they don't say anything. They sound like machine-generated nonsense. Can you actually provide a concrete example of a concrete problem you want to solve with the token-based UI initiative? Write your answer following the STAR format, and leave the buzzword bingo out. If you cannot explain your problem then this is a very clear tell that it might not exist at all.
  - kaelig 2y ago
    > They sound like machine-generated nonsense. Fair! Perhaps I should have used an LLM to de-bullshitify my message... Let's walk through a common scenario: Design tool A has brand colors coded in hexadecimal, those have no name, they're just hex values. Design tool B has colors named in CamelCase, values in HSL. Codebases A, B, C have colors in RGB, named the same as in Design Tool B. Codebase D has colors in Hex8, with their own naming convention. 100s of developers copy/paste values from old and new designs over the span of several years. Codebases now have 50 shades of the "primary blue" scattered around. Now user experience feels disjointed at best, confusing and hostile at worst. Engineering design collaboration is tough as no two tools and teams speak the same "design language". Say a team wants to implement a new feature across multiple codebases where styling and naming are all different. Lacks of re-use and poor communication leads to entropy, which leads to poor quality and slower delivery. Design tokens are the interoperable layer that help define a common language across people and tools and improve what I described above. (for those familiar with DDD, there are a lot of similarities) The spec itself is baking this into the entire toolchain so it's available to teams by default, without requiring as much custom tooling. PS: the scenario above may seem extreme to some, but it's _extremely_ common at medium to large companies with no established design/engineering processes.