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

91–100 of 143 posts

Re: Design Token-Based UI Architecture

#91

Post by noworriesnate »

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 the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?

Re: Design Token-Based UI Architecture

#92

Post by kaelig »

taeric wrote: post #87

As I get older, I have grown to really distrust any technological choice of having a "single source of truth" and "Cross-Disciplinary" concerns. Having a tool reconcile data across sources makes sense. Having a single source, sadly, does not. Especially not when you are forcing stakeholders/users to either use a new tool for this, or worse, to change their vocabulary and tooling to support it. So, I get the desire. I…

You're right in that the "centralized single source of truth" actually rarely is a thing at scale.

It's common to adopt a mixed approach: some design tokens make sense to centralize (like global brand colors), and others are local, such as tokens for a specific product or sub-brand.

For example, a web app can build its own token architecture based on an existing foundation shared with iOS and Android apps. They share _some_ concerns, but technical implementations differ they may offer different theming features, too.

Re: Design Token-Based UI Architecture

#93

Post by motorest »

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

Can you explain what problem you are trying to solve, and how do you think is the best way to solve it?

The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.

Re: Design Token-Based UI Architecture

#94

Post by kaelig »

taeric wrote: post #90
hammock wrote: post #88

Earlier quoted context omitted.

What is the alternative? "Having a tool reconcile data across sources " ? Is that more or less hard?

Most realistically, the main alternative will be processes focused on product release. With a statistical acceptance of mistakes. Consider that Coke has a specific shade that they have used for a long time. My main problems with efforts like this is that they cannot distinguish between different organizational priorities on design considerations and they make virtually no allowance for what different practitioners ar…

> processes focused on product release

+10000

As I mentioned in a couple of my other messages, beware of people over-systematizing and over-centralizing, as it can come at the cost of delivery efficiency and defeats the point of operationalizing design. Plus, it creates a growing maintenance burden on the team maintaining that single source of truth.

Re: Design Token-Based UI Architecture

#95

Post by whoisstan »

ActionHank wrote: post #85
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…

It makes sense, but I struggle to see the value outside of whitelabel products that you may look to rebrand, but with the same UI. Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change. You eventually end up with a rebranding and along with that some sort of UI refactoring. This approach is incredibly valuable when building something th…

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.

Re: Design Token-Based UI Architecture

#96

Post by kaelig »

motorest wrote: post #93
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 (...) Can you explain what problem you are trying to solve, and how do you think is the best way to solve it? The main take from this discussion is that this talk about "design tokens" is that this is a non-problem fabricated by self-promotion types that is trying to find something for which it can be conceived as a solution. So far it seems it's very hard to even put into words.

A few members and myself have commented to explain in various ways what we're solving.

This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury.

The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.

Re: Design Token-Based UI Architecture

#97

Post by whilenot-dev »

itronitron wrote: post #44
kaelig wrote: post #30

Earlier quoted context omitted.

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

How about instead we just start making companies smaller but have more of them?

The UNIX philosophy doesn't play well with the ego of ones business, unfortunately.

Re: Design Token-Based UI Architecture

#98

Post by kaelig »

noworriesnate wrote: post #91
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 the concept so generic that it's kind of hard to standardize? I.e. some of the values are structured (e.g. margins can have four values), some are colors and some are pixels or rem or whatever... why no just use an existing schema language like JSON Schema?

Colors can be expressed in many ways. For example in Android it's common to see hex codes as #AARRGGBB, but in CSS the alpha is at the end (#RRGGBBAA). With wider gamuts (lch, dcip3...), there are separate channels and alpha is expressed separately. We also need to provide ways for folks to codify dark mode / light mode / high contrast values.

Another example is what we call "aliases" or "references": a token can reference another one. Their resolution process needs to be specified (as in: when exactly does an alias get resolved in the lifecycle, and how tools must process them, whether it's okay to rasterize them in the CSS/XML/JS/.. output, etc).

Note that we intend to provide a JSON schema, and the community has already published a few TypeScript type definitions, linting tools, and build tools based on the spec.

> some are pixels or rem or whatever

The 'or whatever' part is what we're trying to tame. For example an Android app may need to consume 'dp' values, web 'rem', iOS 'pt'... There are tons more examples where platforms differ in how they would express dimensions, typography, color... The spec provides a way to encode the source tokens, and then translation tools handle the conversion to platform-specific values.

Re: Design Token-Based UI Architecture

#99

Post by kaelig »

whoisstan wrote: post #95
ActionHank wrote: post #85

Earlier quoted context omitted.

It makes sense, but I struggle to see the value outside of whitelabel products that you may look to rebrand, but with the same UI. Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change. You eventually end up with a rebranding and along with that some sort of UI refactoring. This approach is incredibly valuable when building something th…

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 balancing act. Let's say you're Adobe, and you want Photoshop/Illustrator/InDesign to feel like a single family of products across web/iOS/iPadOS/Windows: where do you want to let feature teams innovate, and where must they adhere to the system so users can navigate seamlessly across these products and platforms?

Re: Design Token-Based UI Architecture

#100

Post by Joker_vD »

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…

> 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 we keep changing the colours/shapes/general theme/etc. of our brand's logos every nine months or so, do they even matter, really?"

My suspicion is that the answer is "no, not really, that's why we can afford to meddle with them since it's a mostly consequence-free environment, and it distracts busybodies from breaking some actually important aspect of the business".

Post reply on HN