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

[BoorishBears]

Why is Material UI still so comically awful?

M3 is an upgrade but even the "header carousel" component there had me straight up pause and study all the ways it's terrible

From the ripple effect that overflows depending on how wide the text underneath is.

The "back button" which is actually for going from one section to the next

And the way it behaves as I click from section to section using those buttons is "top tier jank" for the lack of a better term

The way it also randomly seems to align or not align the currently selected heading resulting in weird clipping of text that just looks confusing and broken.

The shadow indicating the elevation chance as it goes sticky also looks and feels straight out of Windows 95

Why can't Google just make an aesthetically pleasing UI? It almost feels like Apple and the "modern SaaS template ala WorkOS" guys stole the only two good looking directions for modern UI aesthetics and now Google is stuck pushing along their hideous (but identifiable!) aesthetic along side them.

[yakshaving_jgt]

Fortunately, computers are already really good at finding and replacing strings.

[kaelig]

You can try automating search/replace on hex/hsl/rgb values across all your codebases, but targeting "primary button backgrounds on hover" is only possible with some more advanced tooling in place.

And there's an important runtime aspect when it comes to theming, so it's not just about finding/replacing hardcoded values.

[eviks]

But what you need to replace is semantic strings, which "computers" are really bad at finding, and programmers, thinking it's easy, are really bad at adding

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

[motorest]

> Bootstrap and Sass are for the web.

Cool, so we establish that the likes of Bootstrap and Sass already solve this problem for the web.

> They don't solve the interop problem for Figma/Sketch/Framer

That's irrelevant, isn't it? I mean, do you run apps straight out of Sigma/Sketch/Framer? Do you also think it's reasonable to call out Photoshop/Gimp/MSPaint?

> iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars

You're trying to refer to platforms/OSes, aren't you? Do you think it makes any sense to bundle everything together? Those who work on iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars would certainly look at you perplexed just for suggesting that specifying color schemes even registers as a concern in the whole cross-platform discussion.

>

[kaelig]

> Bootstrap and Sass already solve this problem for the web.

In a vacuum, sure. But products aren't all built in a web-centric vacuum.

> That's irrelevant, isn't it? I mean, do you run apps straight out of Sigma/Sketch/Framer? Do you also think it's reasonable to call out Photoshop/Gimp/MSPaint?

Figma/Sketch/Framer are design and prototyping tools. They are _very_ relevant in how we build products. The back-and-forth between design and engineering leads to better outcomes if both sides speak the same language, and their tools allow them to do so.

(Photoshop/Gimp/MSPaint aren't so relevant un product design)

> Do you think it makes any sense to bundle everything together?

Not everything. You generally want folks using your products across iOS, their car, their TV, and a web browser have a coherent experience. This doesn't mean that everything needs to look exactly the same. It means that key design decisions can be distributed across the board.