11 ms·

Design Token-Based UI Architecture

177 points by mpweiher 2y ago

svachalek 2y ago
It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.
- panic 2y ago
  The core idea seems to be putting visual parameters in a single place that can be shared across platforms. That way you can tweak the design everywhere without having to edit N different platform-specific implementations.
  - deleted 2y ago
    [deleted]
- nikolayasdf123 2y ago
  same. I don't understand what he is talking about. is he working in front-end? sounds like tons of "consulting" talk.
- iLoveOncall 2y ago
  It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.
- MrMcCall 2y ago
  What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment. This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed. It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.
- skybrian 2y ago
  The term “design token” seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the “token” part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors. It’s kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but that’s just how it goes. Inventing jargon isn’t bad. There is certainly a lot of programming jargon that we inflict on others.
nsonha 2y ago
what is so "architecture" about constants?
- CaveTech 2y ago
  The millions of websites designed without using them. This insight was lost at some point, even if it seems obvious in retrospect.
- HexDecOctBin 2y ago
  Consultancy money. Why should Robert Cecil Martin have all the fun? Other Martins want in. There should be some research into how many code bases have been ruined by these panacea peddlers.
- motorest 2y ago
  > what is so "architecture" about constants? I'm all for simplifying the indecipherable, but this is a case where things need to be made as simple as possible, but not simpler. Design systems determine how everything looks and feels, and this means specifying a number of things together, such as what colors a button has, how it looks when pressed and hovered, how dialogs look, what is dark mode or light mode, etc. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.
  - deleted 2y ago
    [deleted]
- skybrian 2y ago
  Compare with Cue, Jsonnet, etc. Systems for sharing configuration settings can get pretty elaborate when it’s done at scale.
nikolayasdf123 2y ago
someone should write an article explaining this in folk language
- astr0n0m3r 2y ago
  In one sentence: Design tokens are a standardized way of defining constants used in a design system. If most developers haven't heard of them, it's because most developers don't create design systems. Even when you use a design system, the actual use of design tokens would likely be hidden. Material Design uses them. https://m3.material.io/foundations/design-tokens/overview https://m3.material.io/foundations/design-tokens/overview Fluent UI uses them. https://fluent2.microsoft.design/design-tokens https://fluent2.microsoft.design/design-tokens
  - HexDecOctBin 2y ago
    So, basically #define?
    - nikolayasdf123 2y ago
      yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer
      - aaronbrethorst 2y ago
        The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.
        tinix 2y ago
        This kind of comment isn't welcome here...
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.
pavlov 2y ago
CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.
- bradhe 2y ago
  I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise that’s done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and there’s tons of stakeholders you have to align due to the risk to the brand. Front end engineers love to opine over amazingly flexible design systems, though.
  - kaelig 2y ago
    This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize". That said, it's not just about "updatability" of systems, it's in great part about scaling a design language across multiple surfaces, products, modes, locales, and sometimes even multiple brands. The orthogonal complexity of design decisions can be pretty high, and does requires powerful interoperable tooling to handle. Hence the need for this methodology and a spec.
  - yowzadave 2y ago
    Yes, and also design changes never seem to align precisely with the parameters you anticipated at the beginning. I.e., you don’t just need to update one color variable, you need to update that color AND add a secondary accent color AND change the positioning of the logo with respect to the company name, etc.
- seanwilson 2y ago
  > CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers. Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.
seanwilson 2y ago
Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs: 1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code. 2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast. 3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages. Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices). I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers! UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before? Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers. The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.
tuzemec 2y ago
We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo. We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects. Everything was working great until the designers decided the existing tokens were insufficient, and new designers joined who simply chose not to use them (because... reasons). My point is that tokens work well when there is full alignment between the design and engineering teams. However, it requires extra effort from both sides to consistently "follow the rules". [1] - https://tokens.studio/plugin https://tokens.studio/plugin [2] - https://amzn.github.io/style-dictionary/#/ https://amzn.github.io/style-dictionary/#/
- martinsnow 2y ago
  Of course. If you don't design your system right and enforce consistency it will be a mess. That's programming and pretty much engineering in a nutshell.
block_dagger 2y ago
“Tokens” makes me think of crypto/blockchain. Suboptimal naming.
- kaelig 2y ago
  For context, this name was coined 10 years ago, before the crypto/blockchain craze.
GiorgioG 2y ago
> There's a whole movement bringing DevOps and SRE thinking to design/UX Heaven help us. Hope this dies a quick death.
- kaelig 2y ago
  Say more
  - GiorgioG 2y ago
    > DevOps and SRE thinking DevOps thinking is exactly what got us into this IaC mess we're in now. Back in the day (like 15 years ago), things were actually simpler - you were either dev or ops, period. But then K8s and all that jazz came along, and suddenly we need this whole army of "DevOps engineers" just to keep the lights on and make everything 10x more complicated than it needs to be. And please don't say "yes but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'. I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate? The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve. I can't wait for Design Token Engineers to become a thing /s
    - kaelig 2y ago
      Thank you for sharing — sounds like we've had different experiences but I can absolutely see how poorly implemented devops is worse than well-implemented ops. I've written about operationalizing design and design/engineering collaboration for a while now, and work at a frontend cloud PaaS... So I appreciate hearing from folks outside of my own bubble! The path from idea to production was arduous for frontend and design back in these days. I for one appreciate being able to deploy frontend changes to production in just a few minutes, which the cloud + SRE + DevOps mindsets have helped democratize.
MrMcCall 2y ago
This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment. This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed. It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.
- einsty 2y ago
  I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
  - MrMcCall 2y ago
    Thanks. That's not my workspace, so it makes sense that I would be unaware of it, my just being a programmer.
- strogonoff 2y ago
  “Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”. (The term “variable” may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.) [0] https://github.com/design-tokens/community-group https://github.com/design-tokens/community-group
  - MrMcCall 2y ago
whoisstan 2y ago
This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500. Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.
- strogonoff 2y ago
  Part of the reason I like design tokens is that they are a middle ground between the chaos of utility classes[0] and impracticality of pure semantics, while being in a way better defined than either of them. Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue. [0] When it comes to CSS—of course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
  - whoisstan 2y ago
    Agree, you tap into the rigidness of a semantic color and type hierarchy, while allowing utility classes for specifics of a platform/environment.
- ActionHank 2y ago
  It makes sense, but I struggle to see the value outside of whitelabel products that you may look to rebrand, but with the same UI. Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change. You eventually end up with a rebranding and along with that some sort of UI refactoring. This approach is incredibly valuable when building something that won't change drastically when you are changing those tokens.
  - whoisstan 2y ago
jillesvangurp 2y ago
Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that. Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.
c-hendricks 2y ago
It's not like this is a new concept, here's bootstrap almost 15 years ago: https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/assets/stylesheets/bootstrap/_variables.scss#L50-L55 https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as... https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/assets/stylesheets/bootstrap/_variables.scss#L70-L84 https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
aridiculous 2y ago
Seems like a lot of the comments are not getting it. The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions. Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green. When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time. This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows. It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR. An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.
- psygn89 2y ago
  I think people get hung up on the term "tokens" and imagine something more. They should've kept it simple and called it design variables or something.
  - lyu07282 2y ago
    if this is the first time you heard that term then you will be hopelessly lost, but these concepts are a decade old by now and used by UI teams in every medium/major company in the world. It's well established terminology, if people never heard about it before they should question the validity of their opinions on the matter.
- Joker_vD 2y ago
  > When your brand evolves to a different shade of green This is such a funny line to read. I just can't help but imagine a brand like a small bulbasaur that evolves into big, strong venosaur which of course involves changing its shade of green. > An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?" An even more interesting question would be "if we keep changing the colours/shapes/general theme/etc. of our brand's logos every nine months or so, do they even matter, really?" My suspicion is that the answer is "no, not really, that's why we can afford to meddle with them since it's a mostly consequence-free environment, and it distracts busybodies from breaking some actually important aspect of the business".
taeric 2y ago
As I get older, I have grown to really distrust any technological choice of having a "single source of truth" and "Cross-Disciplinary" concerns. Having a tool reconcile data across sources makes sense. Having a single source, sadly, does not. Especially not when you are forcing stakeholders/users to either use a new tool for this, or worse, to change their vocabulary and tooling to support it. So, I get the desire. It would be nice to have a way to say "this color red is always used for whatever reason." But then you will have people try and layer that on with "for other reasons, things of another type will always be darker by about 4 shades." Someone will see one of these interactions go poorly, and add whatever emphasis they can to the rule they care about. Then the obfuscations begin.
- hammock 2y ago
  What is the alternative? "Having a tool reconcile data across sources " ? Is that more or less hard?
  - taeric 2y ago
    Most realistically, the main alternative will be processes focused on product release. With a statistical acceptance of mistakes. Consider that Coke has a specific shade that they have used for a long time. My main problems with efforts like this is that they cannot distinguish between different organizational priorities on design considerations and they make virtually no allowance for what different practitioners are using today. That later point is the one that drives me the most crazy. We have very few tools that can help reconcile a graphic design to a website. Most of what we have are attempts to change how graphic designs are created so that they can be more directly transferred.
    - kaelig 2y ago
      > processes focused on product release +10000 As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operationalizing design. Plus, it creates a growing maintenance burden on the team maintaining that single source of truth.
braden-lk 2y ago
Design-first thinking with tokens is a game-changer for an org building a product that needs to adapt to multiple clients. It's still useful for a singularly-branded product just for separation-of-concerns reasons, but maybe less useful. Design tokens aren't concerned with implementation. (CSS vars, constants, etc.). Design tokens are an abstraction for standardizing and communicating the values in your design system, regardless of where they show up. Yes, you might implement your design tokens as CSS variables, but not necessarily.
mtmorrow 2y ago
As a dev working with designers who have embraced the Figma token generation, I have to say the whole effort seems ill-conceived. The sheer amount of problems faced with tokens going missing, unclear rationales, endless updates and follow-up, coordination, etc makes me yearn for days where designers dropped a design file and devs figured out if tokenizing made sense. Plus, tokens are only as good as the deeper design decisions, but that abstraction always has consequences. Not to mention the performance impact of css vars. Again, it feels as if the idea has been stretched so designers can change code tokens at will, but to do this would require an insane amount of tokenization that in a sufficiently large code base would become unmanageable. Our latest token count is nearing 5k unique tokens, and that only covers maybe 2% of custom css we have to use to achieve the desired outcome. For me, it’s a net negative.
- kaelig 2y ago
  Thank you for sharing – and good luck, as this is a tough situation to be in. Some teams neglect to consider the entire lifecycle of a token and introduce too many, too early. They can bring a ton of value, but it has to be weighed against the learning curve and maintenance burden. The industry is full of very eager folks who get into design systems but were never on the receiving end of one, and who sometimes overdo it. Like I said in another comment: "systems people will systematize". Design tokens are not the cure nor the problem, but like any approach, it can go wrong when taken too far or is owned by folks too siloed from engineering to realize their full power.
tester756 2y ago
so basically json describing UI for various platforms? like domain specific language
rroose 2y ago
The NL Design System (https://www.nldesignsystem.nl/ https://www.nldesignsystem.nl/) is a project funded by the Dutch government which works with Design Tokens. This way government agencies and municipalities can share components but still retain their own look and feel.

177 points by mpweiher 2y ago

It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.

panic 2y ago
The core idea seems to be putting visual parameters in a single place that can be shared across platforms. That way you can tweak the design everywhere without having to edit N different platform-specific implementations.
- deleted 2y ago
  [deleted]
nikolayasdf123 2y ago
same. I don't understand what he is talking about. is he working in front-end? sounds like tons of "consulting" talk.
iLoveOncall 2y ago
It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.
MrMcCall 2y ago
What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment. This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed. It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.
skybrian 2y ago
The term “design token” seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the “token” part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors. It’s kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but that’s just how it goes. Inventing jargon isn’t bad. There is certainly a lot of programming jargon that we inflict on others.

nsonha 2y ago

what is so "architecture" about constants?

CaveTech 2y ago
The millions of websites designed without using them. This insight was lost at some point, even if it seems obvious in retrospect.
HexDecOctBin 2y ago
Consultancy money. Why should Robert Cecil Martin have all the fun? Other Martins want in. There should be some research into how many code bases have been ruined by these panacea peddlers.
motorest 2y ago
> what is so "architecture" about constants? I'm all for simplifying the indecipherable, but this is a case where things need to be made as simple as possible, but not simpler. Design systems determine how everything looks and feels, and this means specifying a number of things together, such as what colors a button has, how it looks when pressed and hovered, how dialogs look, what is dark mode or light mode, etc. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.
- deleted 2y ago
  [deleted]
skybrian 2y ago
Compare with Cue, Jsonnet, etc. Systems for sharing configuration settings can get pretty elaborate when it’s done at scale.

nikolayasdf123 2y ago

someone should write an article explaining this in folk language

astr0n0m3r 2y ago
In one sentence: Design tokens are a standardized way of defining constants used in a design system. If most developers haven't heard of them, it's because most developers don't create design systems. Even when you use a design system, the actual use of design tokens would likely be hidden. Material Design uses them. https://m3.material.io/foundations/design-tokens/overview https://m3.material.io/foundations/design-tokens/overview Fluent UI uses them. https://fluent2.microsoft.design/design-tokens https://fluent2.microsoft.design/design-tokens
- HexDecOctBin 2y ago
  So, basically #define?
  - nikolayasdf123 2y ago
    yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer
    - aaronbrethorst 2y ago
      The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.
      - tinix 2y ago
        This kind of comment isn't welcome here...

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.

pavlov 2y ago

CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.

bradhe 2y ago
I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise that’s done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and there’s tons of stakeholders you have to align due to the risk to the brand. Front end engineers love to opine over amazingly flexible design systems, though.
- kaelig 2y ago
  This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize". That said, it's not just about "updatability" of systems, it's in great part about scaling a design language across multiple surfaces, products, modes, locales, and sometimes even multiple brands. The orthogonal complexity of design decisions can be pretty high, and does requires powerful interoperable tooling to handle. Hence the need for this methodology and a spec.
- yowzadave 2y ago
  Yes, and also design changes never seem to align precisely with the parameters you anticipated at the beginning. I.e., you don’t just need to update one color variable, you need to update that color AND add a secondary accent color AND change the positioning of the logo with respect to the company name, etc.
seanwilson 2y ago
> CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers. Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.

seanwilson 2y ago

Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs: 1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code. 2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast. 3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages. Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices). I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers! UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before? Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers. The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.

tuzemec 2y ago

We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo. We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects. Everything was working great until the designers decided the existing tokens were insufficient, and new designers joined who simply chose not to use them (because... reasons). My point is that tokens work well when there is full alignment between the design and engineering teams. However, it requires extra effort from both sides to consistently "follow the rules". [1] - https://tokens.studio/plugin https://tokens.studio/plugin [2] - https://amzn.github.io/style-dictionary/#/ https://amzn.github.io/style-dictionary/#/

martinsnow 2y ago
Of course. If you don't design your system right and enforce consistency it will be a mess. That's programming and pretty much engineering in a nutshell.

block_dagger 2y ago

“Tokens” makes me think of crypto/blockchain. Suboptimal naming.

kaelig 2y ago
For context, this name was coined 10 years ago, before the crypto/blockchain craze.

GiorgioG 2y ago

> There's a whole movement bringing DevOps and SRE thinking to design/UX Heaven help us. Hope this dies a quick death.

kaelig 2y ago
Say more
- GiorgioG 2y ago
  > DevOps and SRE thinking DevOps thinking is exactly what got us into this IaC mess we're in now. Back in the day (like 15 years ago), things were actually simpler - you were either dev or ops, period. But then K8s and all that jazz came along, and suddenly we need this whole army of "DevOps engineers" just to keep the lights on and make everything 10x more complicated than it needs to be. And please don't say "yes but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'. I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate? The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve. I can't wait for Design Token Engineers to become a thing /s
  - kaelig 2y ago
    Thank you for sharing — sounds like we've had different experiences but I can absolutely see how poorly implemented devops is worse than well-implemented ops. I've written about operationalizing design and design/engineering collaboration for a while now, and work at a frontend cloud PaaS... So I appreciate hearing from folks outside of my own bubble! The path from idea to production was arduous for frontend and design back in these days. I for one appreciate being able to deploy frontend changes to production in just a few minutes, which the cloud + SRE + DevOps mindsets have helped democratize.

MrMcCall 2y ago

This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element". Here is my slightly edited comment from below: What they are calling "tokens" are just their design elements. They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment. This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed. It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.

einsty 2y ago
I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
- MrMcCall 2y ago
  Thanks. That's not my workspace, so it makes sense that I would be unaware of it, my just being a programmer.
strogonoff 2y ago
“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”. (The term “variable” may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.) [0] https://github.com/design-tokens/community-group https://github.com/design-tokens/community-group
- MrMcCall 2y ago

whoisstan 2y ago

This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500. Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic styling over the onslaught of classes in i.e. tailwind.

strogonoff 2y ago
Part of the reason I like design tokens is that they are a middle ground between the chaos of utility classes[0] and impracticality of pure semantics, while being in a way better defined than either of them. Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue. [0] When it comes to CSS—of course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
- whoisstan 2y ago
  Agree, you tap into the rigidness of a semantic color and type hierarchy, while allowing utility classes for specifics of a platform/environment.
ActionHank 2y ago
It makes sense, but I struggle to see the value outside of whitelabel products that you may look to rebrand, but with the same UI. Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change. You eventually end up with a rebranding and along with that some sort of UI refactoring. This approach is incredibly valuable when building something that won't change drastically when you are changing those tokens.
- whoisstan 2y ago

jillesvangurp 2y ago

Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that. Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.

c-hendricks 2y ago

It's not like this is a new concept, here's bootstrap almost 15 years ago: https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/assets/stylesheets/bootstrap/_variables.scss#L50-L55 https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as... https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/assets/stylesheets/bootstrap/_variables.scss#L70-L84 https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...

aridiculous 2y ago

Seems like a lot of the comments are not getting it. The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions. Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green. When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time. This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows. It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR. An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.

psygn89 2y ago
I think people get hung up on the term "tokens" and imagine something more. They should've kept it simple and called it design variables or something.
- lyu07282 2y ago
  if this is the first time you heard that term then you will be hopelessly lost, but these concepts are a decade old by now and used by UI teams in every medium/major company in the world. It's well established terminology, if people never heard about it before they should question the validity of their opinions on the matter.
Joker_vD 2y ago
> When your brand evolves to a different shade of green This is such a funny line to read. I just can't help but imagine a brand like a small bulbasaur that evolves into big, strong venosaur which of course involves changing its shade of green. > An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?" An even more interesting question would be "if we keep changing the colours/shapes/general theme/etc. of our brand's logos every nine months or so, do they even matter, really?" My suspicion is that the answer is "no, not really, that's why we can afford to meddle with them since it's a mostly consequence-free environment, and it distracts busybodies from breaking some actually important aspect of the business".

taeric 2y ago

As I get older, I have grown to really distrust any technological choice of having a "single source of truth" and "Cross-Disciplinary" concerns. Having a tool reconcile data across sources makes sense. Having a single source, sadly, does not. Especially not when you are forcing stakeholders/users to either use a new tool for this, or worse, to change their vocabulary and tooling to support it. So, I get the desire. It would be nice to have a way to say "this color red is always used for whatever reason." But then you will have people try and layer that on with "for other reasons, things of another type will always be darker by about 4 shades." Someone will see one of these interactions go poorly, and add whatever emphasis they can to the rule they care about. Then the obfuscations begin.

hammock 2y ago
What is the alternative? "Having a tool reconcile data across sources " ? Is that more or less hard?
- taeric 2y ago
  Most realistically, the main alternative will be processes focused on product release. With a statistical acceptance of mistakes. Consider that Coke has a specific shade that they have used for a long time. My main problems with efforts like this is that they cannot distinguish between different organizational priorities on design considerations and they make virtually no allowance for what different practitioners are using today. That later point is the one that drives me the most crazy. We have very few tools that can help reconcile a graphic design to a website. Most of what we have are attempts to change how graphic designs are created so that they can be more directly transferred.
  - kaelig 2y ago
    > processes focused on product release +10000 As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operationalizing design. Plus, it creates a growing maintenance burden on the team maintaining that single source of truth.

braden-lk 2y ago

Design-first thinking with tokens is a game-changer for an org building a product that needs to adapt to multiple clients. It's still useful for a singularly-branded product just for separation-of-concerns reasons, but maybe less useful. Design tokens aren't concerned with implementation. (CSS vars, constants, etc.). Design tokens are an abstraction for standardizing and communicating the values in your design system, regardless of where they show up. Yes, you might implement your design tokens as CSS variables, but not necessarily.

mtmorrow 2y ago

As a dev working with designers who have embraced the Figma token generation, I have to say the whole effort seems ill-conceived. The sheer amount of problems faced with tokens going missing, unclear rationales, endless updates and follow-up, coordination, etc makes me yearn for days where designers dropped a design file and devs figured out if tokenizing made sense. Plus, tokens are only as good as the deeper design decisions, but that abstraction always has consequences. Not to mention the performance impact of css vars. Again, it feels as if the idea has been stretched so designers can change code tokens at will, but to do this would require an insane amount of tokenization that in a sufficiently large code base would become unmanageable. Our latest token count is nearing 5k unique tokens, and that only covers maybe 2% of custom css we have to use to achieve the desired outcome. For me, it’s a net negative.

kaelig 2y ago
Thank you for sharing – and good luck, as this is a tough situation to be in. Some teams neglect to consider the entire lifecycle of a token and introduce too many, too early. They can bring a ton of value, but it has to be weighed against the learning curve and maintenance burden. The industry is full of very eager folks who get into design systems but were never on the receiving end of one, and who sometimes overdo it. Like I said in another comment: "systems people will systematize". Design tokens are not the cure nor the problem, but like any approach, it can go wrong when taken too far or is owned by folks too siloed from engineering to realize their full power.

tester756 2y ago

so basically json describing UI for various platforms? like domain specific language

rroose 2y ago

The NL Design System (https://www.nldesignsystem.nl/ https://www.nldesignsystem.nl/) is a project funded by the Dutch government which works with Design Tokens. This way government agencies and municipalities can share components but still retain their own look and feel.