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

21–30 of 143 posts

Re: Design Token-Based UI Architecture

#21

Post by anentropic »

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…

"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

Re: Design Token-Based UI Architecture

#22

Post by kaelig »

AdieuToLogic wrote: post #19
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…

> Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques? In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]? 0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropo…

It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc.

At a certain scale, design and brand teams need infrastructure to drive change. These teams rarely have sufficient engineering headcount (if any) to build such tooling and delivery pipelines all the way to the user. Having interoperable formats brings alignment across design and engineering toolchains. The industry needs this methodology to be baked in, rather than requiring folks to build their own tooling.

Re: Design Token-Based UI Architecture

#23

Post by et1337 »

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…

Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything?

And if that’s not the goal, what is the goal?

Re: Design Token-Based UI Architecture

#24

Post by spankalee »

kaelig wrote: post #20
spankalee wrote: post #16

Earlier quoted context omitted.

Why does the format use $-prefixed keys? That's pretty weird as far as JSON schemas go.

The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions As for the "pretty weird" aspect — it's definitely uncommon but it's been seen before: the $ prefix is also used by the JSON Reference ($ref): https://www.ietf.org/archive/id/dra…

You can usually do this by only being additive with the spec, and by never mixing user-defined keys and spec-defined keys in the same object.

I've only ever seen $ used before with meta properties that work across all schemas like the $ref you mentioned and $schema.

Re: Design Token-Based UI Architecture

#25

Post by kaelig »

et1337 wrote: post #23
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…

Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? And if that’s not the goal, what is the goal?

> Is the goal to be able to change a design token and see that change reflected across all your various UIs?

That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a PR for example)

> How do you ensure people remember to use the design token instead of hardcoding the value?

A combination of great docs, education (onboarding, training), autocomplete, and linting. In design tools, it's baked in to the UI so adoption is less of a problem.

> Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything?

Yes, and that's where visual regression testing comes in and proves valuable to not just developers, but also designers.

Re: Design Token-Based UI Architecture

#26

Post by kaelig »

anentropic wrote: post #21
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…

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

Re: Design Token-Based UI Architecture

#27

Post by mcrider »

et1337 wrote: post #23
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…

Is the goal to be able to change a design token and see that change reflected across all your various UIs? How do you ensure people remember to use the design token instead of hardcoding the value? Won’t you still have to check every nook and cranny of the UI to make sure the change doesn’t break anything? And if that’s not the goal, what is the goal?

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 minimal developer supervision, which has been a huge time saver and QoL improvement for both developers and designers.

Re: Design Token-Based UI Architecture

#28

Post by nsonha »

tinix wrote: post #15
aaronbrethorst wrote: post #13

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

Said who, a consultant?

Re: Design Token-Based UI Architecture

#29

Post by starbugs »

kaelig wrote: post #22
AdieuToLogic wrote: post #19

Earlier quoted context omitted.

> Ask me anything — this may be confusing to some folks ("isn't it just... variables?") and I'm happy to say more. How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques? In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]? 0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropo…

It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc. At a certain scale, design and brand teams need infrastru…

> At a certain scale, design and brand teams need infrastructure to drive change

What does this mean?

Do you have a concrete example of where this actually solves a real problem? And what problem would that be?

Re: Design Token-Based UI Architecture

#30

Post by kaelig »

starbugs wrote: post #29
kaelig wrote: post #22

Earlier quoted context omitted.

It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, React Native iOS, Android, Figma, various prototyping tools, and for several company brands, dark mode, high contrast mode, etc. At a certain scale, design and brand teams need infrastru…

> At a certain scale, design and brand teams need infrastructure to drive change What does this mean? Do you have a concrete example of where this actually solves a real problem? And what problem would that be?

Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent.

Now imagine rolling out dark mode across an entire suite of products, or perhaps a brand refresh.

Having a single source of truth and tooling that supports it end to end from design to engineering helps roll out changes fast and on brand. In turn, it's good for the user!

I know a lot of folks here may come from a more backend background so it may help to think of it as: a way to unlock continuous delivery for your design decisions.

Post reply on HN