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

121–130 of 143 posts

Re: Design Token-Based UI Architecture

#121

Post by kaelig »

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?

They can be constants, but not always: 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 happen at runtime or at build time depending on the use-case.

Examples: - "primary button background color" may be different across light and dark mode - "header height" can vary across small and large viewports - "user avatar background" may be defined by the user themselves - "brand primary" may change for re-usable UI components based on the brand they're used for

Re: Design Token-Based UI Architecture

#122

Post by yowzadave »

bradhe wrote: post #36
pavlov wrote: post #34

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.

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

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.

Re: Design Token-Based UI Architecture

#123

Post by kaelig »

motorest wrote: post #117
kaelig wrote: post #113

Earlier quoted context omitted.

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.

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

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

Re: Design Token-Based UI Architecture

#124

Post by kaelig »

bmelton wrote: post #120
kaelig wrote: post #109

Earlier quoted context omitted.

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

Great answer. In your scenarios, let's say OrangeCorp has their 'brand-orange' color token. They've defined it as the hexadecimal `#FFA500`. Engineer Bob implements it as `hsl(39, 100%, 50%)` in a web project because the loading state requires shifting the color values, and he has a library that works with HSL but doesn't work hex. What do you store for the source of truth? Are we just storing the hex value, and deri…

The "fun" part with HSL is that RGB->HSL->RGB conversion doesn't always land back on the initial value (and that's why I discourage using HSL altogether).

In orgs without design tokens, I forgot to mention there's also number of folks using the color picker from their OS to grab what they think will be the right color, sometimes even on lossy images like a PNG, JPG, GIF... and that's how you end up with the 50 shades of blue.

Re: Design Token-Based UI Architecture

#125

Post by lyu07282 »

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…

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

Re: Design Token-Based UI Architecture

#126

Post by BoorishBears »

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…

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.

Re: Design Token-Based UI Architecture

#127

Post by lyu07282 »

psygn89 wrote: post #89
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…

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.

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.

Re: Design Token-Based UI Architecture

#128

Post by anentropic »

kaelig wrote: post #26
anentropic wrote: post #21

Earlier quoted context omitted.

"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

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.

ok, so the concept of layers is built in but not which layers

Re: Design Token-Based UI Architecture

#129

Post by mcrider »

bung wrote: post #41
mcrider wrote: post #27

Earlier quoted context omitted.

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

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

We use a Figma plugin called Tokens Studio, which stores its source of truth a (a big JSON file) in our github repo. Designers manage all of the token values there and push updates to a branch and create their own pull requests which developers then do a minimal review on. Long story short, the tokens are converted to CSS variables, which we consume in our styles (we use Vanilla Extract which makes this very nice). The tokens in Token Studio can also be used in the Figma designs, but its a little clunky.

Figma recently launched their own native solution (called Figma Variables) which is more slick and better integrates into the design tooling, but it is mostly locked behind an enterprise-level plan (which lots of folks aren't happy about)

Re: Design Token-Based UI Architecture

#130

Post by whoisstan »

kaelig wrote: post #99
whoisstan wrote: post #95

Earlier quoted context omitted.

It has to be useful for large organizations like for example IBM who need to maintain consistency on various domains, displays and media types. But I suspect it also can stiffle innovation.

It also helps small teams build faster. A shared language around color, spacing, typography makes design/engineering collaboration way smoother, and reduces rework. A good first step is to have your color palette in your design tool of choice consistent with the variable names used in CSS. > But I suspect it also can stiffle innovation. Like any system: it can both be empowering or the opposite. It's a tough balancin…

Its like parenting, be loose and strict in the same way. You have to find a good balance given the team composition and corporate restrictions.
Post reply on HN