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

131–140 of 143 posts

Re: Design Token-Based UI Architecture

#131

Post by mtmorrow »

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.

Re: Design Token-Based UI Architecture

#132

Post by kaelig »

mtmorrow wrote: post #131

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…

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.

Re: Design Token-Based UI Architecture

#133

Post by eviks »

yakshaving_jgt wrote: post #103
kaelig wrote: post #101

Earlier quoted context omitted.

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.

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

Re: Design Token-Based UI Architecture

#134

Post by meiraleal »

kaelig wrote: post #121
meiraleal wrote: post #107

Earlier quoted context omitted.

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

light/dark mode as user setting is a variable, current viewport too. But the dark primary button background color and light primary button background color are constants in a design system.

> "user avatar background" may be defined by the user themselves

Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user preference and its lifecycle has little to do with the design architecture of the product.

Re: Design Token-Based UI Architecture

#135

Post by kaelig »

meiraleal wrote: post #134
kaelig wrote: post #121

Earlier quoted context omitted.

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

light/dark mode as user setting is a variable, current viewport too. But the dark primary button background color and light primary button background color are constants in a design system. > "user avatar background" may be defined by the user themselves Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user pref…

> But the dark primary button background color and light primary button background color are constants in a design system.

They are not necessarily constants, and _could_ point to a theme's value, or even be generated on the fly.

> Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user preference and its lifecycle has little to do with the design architecture of the product.

That's a choice you can absolutely make for your use-case.

A design token _can_ be a named design property with a dynamic value, and sometimes a fallback. User preferences _can_ feed values into existing tokens.

The important part is that design and engineering are speaking the same language when referring to these – you're free to tokenize these or not.

Re: Design Token-Based UI Architecture

#136

Post by GiorgioG »

kaelig wrote: post #84
GiorgioG wrote: post #80

Earlier quoted context omitted.

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

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

In your 'about', you have worked with/at well-respected tech companies. I suspect they had significant investment in their DevOps teams and that has not been my experience at large non-tech companies in my career. Our differing experiences make sense when thinking about it in that context.

Re: Design Token-Based UI Architecture

#137

Post by starbugs »

kaelig wrote: post #81
s2l wrote: post #63

Earlier quoted context omitted.

> or perhaps a brand refresh. Doesn't brand refresh often includes new components and new design language? In creative space, every design agency tries to sell something different to the organization and thus brand refresh will discontinue any prior design tokens and come up with new one.

"it depends" When working on products that can last decades, you can't just throw away all styling and start from scratch. In this case, design tokens are essentially styling hooks that allow teams to propagate design changes at scale without rebuilding everything.

> design tokens

> styling hooks

You mean variables.

I don't get why the marketing speak is necessary. I also think it's detrimental to what we've built as engineers. Please stop. It's neither a token nor a hook, it's a simple variable.

Re: Design Token-Based UI Architecture

#138

Post by kaelig »

starbugs wrote: post #137
kaelig wrote: post #81

Earlier quoted context omitted.

"it depends" When working on products that can last decades, you can't just throw away all styling and start from scratch. In this case, design tokens are essentially styling hooks that allow teams to propagate design changes at scale without rebuilding everything.

> design tokens > styling hooks You mean variables. I don't get why the marketing speak is necessary. I also think it's detrimental to what we've built as engineers. Please stop. It's neither a token nor a hook, it's a simple variable.

It goes beyond variables. At the minimum it's a name and a static or dynamic value, but it can also contain metadata, transforms, private/public attributes, formatting constraints...

You may not be aware (and 10 years late in trying to stop this), but this name has been very well received in the web design industry and frontend world and helps us build a community of craft to solve similar problems together.. so it looks like it's here to stay.

Re: Design Token-Based UI Architecture

#139

Post by [deleted] »

motorest wrote: post #52
nsonha wrote: post #3

what is so "architecture" about constants?

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

[deleted]

Re: Design Token-Based UI Architecture

#140

Post by nsonha »

GiorgioG wrote: post #80
kaelig wrote: post #65

Earlier quoted context omitted.

Say more

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

Design System Engineer/Designer is already a thing
Post reply on HN