[aridiculous]

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.

[groby_b]

> This is an organizational tool that increases in value as a multi-platform company grows.

That sounds impressive enough for the UX sales presentation. Meanwhile, how is it any different from "don't just use numbers, use an agreed-upon set of constants"?

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

Awesome. And I assume all contrast issues fix themselves? So do color clashes? No? Designers still need to consider their change in context? So, again, how is it different from a set of agreed-upon constants?

CSS variables and derived values are a way to implement those constants. Not the only one, but a decent one. Yes, you need to properly resolve dependencies/propagate values, but you need to do that with any other implementation as well.

Sure, call it design tokens instead of constants - but is there any difference? I'm really trying to understand how this is contributing anything on top of symbolic referents. Something that at least on the engineering side is well known since before the infamous "should the value of pi change" manual entry.

[kaelig]

It's not too different, as the concept was heavily influenced by localization libraries.

That said they're not always constants. A design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can apply at runtime or at build time depending on the use-case.

[lyu07282]

I suspect commenters already don't quite get the point of design systems in the first place, this UI architecture idea goes several steps beyond that. Design systems are already really hard to pull off depending on the people involved, any effort at systematizing that approach are very well worth it, but is going to be met with opposition.

I suspect if you wrote about atomic design[1] for example you would get similar comments.

Also here[2] is an example of a design system to better understand how to extrapolate the "brand color" example.

[1] https://atomicdesign.bradfrost.com/chapter-1/ [2] https://atlassian.design/components/tokens/all-tokens

[Joker_vD]

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

[seanwilson]

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

Facebook updated their main brand blue and other colors in 2023, partly for accessibility: https://design.facebook.com/stories/redefining-facebooks-bra...

Wise also had a rebranding with accessibility in mind: https://the-brandidentity.com/interview/how-the-ragged-edge-...

Figma recently changed their colors too: https://www.figma.com/blog/figma-on-figma-evolving-our-visua...

It won't be just a single color either, but a whole palette for them. It's not practical to do a search/replace of color hexes across all designs and code, because it can depend on context which color is appropriate to use where, especially for accessibility.

It's also the norm I would say for startups and small companies to launch with minimal/good-enough branding (often with poor color contrast for the main brand colors because people love bright colors on white), and then they change/refine it later when it's more important.

Not saying you need design tokens at all stages, but brands do evolve.

[kaelig]

Joke aside, there are truly valid reasons why you'd want to change a single color across dozens of codebases, for what can amount to tens of thousands of occurrences. For example: adjusting link color contrast for accessibility compliance.

Salesforce (where the term "design tokens" was coined) is akin to an operating system for the web, with its own app ecosystem. Developers building Salesforce apps can blend into the Salesforce ecosystem thanks to their design system and design tokens.

And I recommend reading https://m3.material.io/foundations/design-tokens/overview to see how Google allows Android app developers to build incredibly expressive and user-personalizable UIs using design tokens.

[psygn89]

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]

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.

[motorest]

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

Perhaps I'm missing something, but Bootstrap does support this, doesn't it?

https://getbootstrap.com/docs/5.2/customize/css-variables/

Please explain why you feel this usecase hasn't already been supported for years.

Also, other tools such as sass also support this feature.

https://sass-lang.com/documentation/variables/

Can you elaborate why you think this problem isn't a solved problem?

[have_faith]

The point of design tokens is that they sit above your framework and library choices, so it's not possible for bootstrap to solve this as it's a down-stream library. Bootstrap is a consumer of design tokens in that they might be fed into bootstraps css variable system. But in a design token system you wouldn't use bootstrap as a source of truth for these tokens, you want something more flexible and programatically portable than CSS.

[kaelig]

Bootstrap and Sass are for the web. They don't solve the interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars and what have you.

And that's not even accounting for web styling solutions that don't use CSS variables.