Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Token-Based UI Architecture

martinfowler.com

Post reply on HN
Print view View original

101–110 of 143 posts

Re: Design Token-Based UI Architecture

#101

Post by kaelig »

Joker_vD wrote: post #100
aridiculous wrote: post #86

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…

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

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.

Re: Design Token-Based UI Architecture

#102

Post by motorest »

kaelig wrote: post #96
motorest wrote: post #93

Earlier quoted context omitted.

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

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 toolin…

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.

Re: Design Token-Based UI Architecture

#103

Post by yakshaving_jgt »

kaelig wrote: post #101
Joker_vD wrote: post #100

Earlier quoted context omitted.

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

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 th…

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

Re: Design Token-Based UI Architecture

#104

Post by motorest »

aridiculous wrote: post #86

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…

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

Re: Design Token-Based UI Architecture

#105

Post by meiraleal »

kaelig wrote: post #94
taeric wrote: post #90

Earlier quoted context omitted.

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 ar…

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

> 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

Yes but also be aware of systems (or lack of) that people deliver crap fast (which is only better than delivering crap slowly).

Re: Design Token-Based UI Architecture

#106

Post by seanwilson »

Joker_vD wrote: post #100
aridiculous wrote: post #86

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…

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

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

Re: Design Token-Based UI Architecture

#107

Post by meiraleal »

rendaw wrote: post #49
kaelig wrote: post #26

Earlier quoted context omitted.

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.

Why call it tokens instead of variables?

because they are constants, not really variables?

Re: Design Token-Based UI Architecture

#108

Post by groby_b »

aridiculous wrote: post #86

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…

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

Re: Design Token-Based UI Architecture

#109

Post by kaelig »

motorest wrote: post #102
kaelig wrote: post #96

Earlier quoted context omitted.

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 toolin…

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.

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

Re: Design Token-Based UI Architecture

#110

Post by seanhunter »

meiraleal wrote: post #107
rendaw wrote: post #49

Earlier quoted context omitted.

Why call it tokens instead of variables?

because they are constants, not really variables?

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

Post reply on HN