Live data from Hacker News

Design Token-Based UI Architecture

martinfowler.com

51–60 of 143 posts

Re: Design Token-Based UI Architecture

#51
post #15

Earlier quoted context omitted.

The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.

This kind of comment isn't welcome here...

> This kind of comment isn't welcome here...

Not true. This kind of comment is exactly why most of us flock to this site. It's important to point out when the emperor wears no clothes. There's already an army of self-promotipn types forcing this nonsense onto everyone.

Re: Design Token-Based UI Architecture

#52
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. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.

Re: Design Token-Based UI Architecture

#53

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.

It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.

Re: Design Token-Based UI Architecture

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

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

I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers.

Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.

Re: Design Token-Based UI Architecture

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

The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?

Re: Design Token-Based UI Architecture

#56
post #49
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?

A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term.

I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!

Re: Design Token-Based UI Architecture

#58
post #38

Earlier quoted context omitted.

The role of the spec is to have alignment throughout proprietary and open source toolchains, from design tools to CI build scripts to UI frameworks, so everyone working on an experience can speak the same language, have high fidelity end to end, and reusable automations. The idea that this can be solved through accountability doesn't scale in my experience. So much of this work is maniacal and low-value, there's very…

> early on their design maturity journey I would argue that it's not in anyone's interest to add such kind of complexity when it's not needed.

Correct, I'm fact I've advised a few teams to only introduce layers of abstraction they needed and could actively document & support.

It's very tempting to copy fortune 500 companies because they're the ones with design & engineering who'll have written the most about this... but most folks just need a pretty simple token setup.

Post reply on HN