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

71–80 of 143 posts

Re: Design Token-Based UI Architecture

#71

Post by strogonoff »

MrMcCall wrote: post #69
strogonoff wrote: post #67

Earlier quoted context omitted.

“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”. (The term “variable” may be more fitting, but it is on the other hand too generic and c…

Thanks. That makes sense, even if my old-school brain finds the term less than optimal.

As an old-school designer, I didn’t like the term at first, but to be honest it is winning me.

I was taught design in terms of design models and design systems, so there was not much of a leap to “design token” as referring to a building block.

I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are tied. At the same time, I can see how even while using tokens it is entirely possible to design a bad interface. However, I also see value of them when it comes to maintaining consistent and intuitive UIs.

Re: Design Token-Based UI Architecture

#72

Post by jillesvangurp »

Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that.

Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.

Re: Design Token-Based UI Architecture

#73

Post by MrMcCall »

strogonoff wrote: post #71
MrMcCall wrote: post #69

Earlier quoted context omitted.

Thanks. That makes sense, even if my old-school brain finds the term less than optimal.

As an old-school designer, I didn’t like the term at first, but to be honest it is winning me. I was taught design in terms of design models and design systems, so there was not much of a leap to “design token” as referring to a building block. I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are t…

> I also see value of them when it comes to maintaining consistent and intuitive UIs

Absolutely. It's like the proper legacy of the GoF's "Design Patterns" book, whose lack of importance and acceptance has bewildered me for close on 30yrs now. Of course, it also means I have rich fields to till for my own work, so bwahaha :-)

[Note that the actual design patterns described in their book are not the important part; their understanding that we must implement software using patterns is their most important concept.]

Re: Design Token-Based UI Architecture

#74

Post by strogonoff »

whoisstan wrote: post #70

This makes sense to me, but it seems to contrary to the current utility-based css wave. For example 'text-red-100' for error message text wouldn't be in style dictionary like that, it would be 'text-color-error' since using 'text-red-100' would always be red 100 and not able to change the text-yellow-500. Point being isn't that a route back to semantic styling? I much prefer the maintainability cycles of semantic sty…

Part of the reason I like design tokens is that they are a middle ground between the chaos of utility classes[0] and impracticality of pure semantics, while being in a way better defined than either of them.

Want a token for a colour with negative semantics? Sure! A token for chartreuse-200? Be my guest! At least, chartreuse-200 on your page will be the same as chartreuse-200 on my page, so that the look is consistent and without distracting incidental variation in hue.

[0] When it comes to CSS—of course, design tokens reside on another layer of abstraction, not tied to any particular implementation.

Re: Design Token-Based UI Architecture

#75

Post by skybrian »

svachalek wrote: post #2

It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.

The term “design token” seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the “token” part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors.

It’s kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but that’s just how it goes. Inventing jargon isn’t bad. There is certainly a lot of programming jargon that we inflict on others.

Re: Design Token-Based UI Architecture

#76

Post by arkh »

strogonoff wrote: post #71
MrMcCall wrote: post #69

Earlier quoted context omitted.

Thanks. That makes sense, even if my old-school brain finds the term less than optimal.

As an old-school designer, I didn’t like the term at first, but to be honest it is winning me. I was taught design in terms of design models and design systems, so there was not much of a leap to “design token” as referring to a building block. I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are t…

You can already imagine OS vendors publishing their design tokens to let you "easily" integrate your applications even if not using their UI libraries.

Re: Design Token-Based UI Architecture

#77

Post by kaelig »

jastuk wrote: post #61
kaelig wrote: post #14

Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1] There's a whole movement bringing DevOps and SRE thinking to design/UX, essentially working on design infrastructure. Design Tokens are a part of it. Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. 1: https://t…

I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now. I could be out of the loop a bit, but I see that this spec is also still a draft…

It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild.

The main areas that need work for us to publish a "V1" are: - colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years) - "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.

Re: Design Token-Based UI Architecture

#78

Post by arkh »

nikolayasdf123 wrote: post #12
HexDecOctBin wrote: post #10

Earlier quoted context omitted.

So, basically #define?

yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer

Well you could distill most "modern" methods to one subtitle of The Mythical Man-Month book: Plan the system for change.

TDD, DDD, extreme programming etc come from the same observation: the client does not know their needs. Even if they do, those could change. So you want to build systems which are easy to change. And we still get thousands of pages published in the form of books or blog post for something written and explained in a book almost 50 years ago.

Re: Design Token-Based UI Architecture

#80

Post by GiorgioG »

kaelig wrote: post #65
GiorgioG wrote: post #60

> There's a whole movement bringing DevOps and SRE thinking to design/UX Heaven help us. Hope this dies a quick death.

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 but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'.

I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate?

The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve.

I can't wait for Design Token Engineers to become a thing /s

Post reply on HN