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

81–90 of 143 posts

Re: Design Token-Based UI Architecture

#81

Post by kaelig »

s2l wrote: post #63
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…

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

Re: Design Token-Based UI Architecture

#82

Post by whoisstan »

strogonoff wrote: post #74
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 consisten…

Agree, you tap into the rigidness of a semantic color and type hierarchy, while allowing utility classes for specifics of a platform/environment.

Re: Design Token-Based UI Architecture

#84

Post by kaelig »

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…

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 design back in these days. I for one appreciate being able to deploy frontend changes to production in just a few minutes, which the cloud + SRE + DevOps mindsets have helped democratize.

Re: Design Token-Based UI Architecture

#85

Post by ActionHank »

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 that won't change drastically when you are changing those tokens.

Re: Design Token-Based UI Architecture

#86

Post by aridiculous »

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 value in one place. All of the above surfaces are updated at the same time.

This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows.

It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR.

An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.

Re: Design Token-Based UI Architecture

#87

Post by taeric »

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. It would be nice to have a way to say "this color red is always used for whatever reason." But then you will have people try and layer that on with "for other reasons, things of another type will always be darker by about 4 shades." Someone will see one of these interactions go poorly, and add whatever emphasis they can to the rule they care about. Then the obfuscations begin.

Re: Design Token-Based UI Architecture

#88

Post by hammock »

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…

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

Re: Design Token-Based UI Architecture

#89

Post by psygn89 »

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…

I think people get hung up on the term "tokens" and imagine something more. They should've kept it simple and called it design variables or something.

Re: Design Token-Based UI Architecture

#90

Post by taeric »

hammock wrote: post #88
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…

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 are using today.

That later point is the one that drives me the most crazy. We have very few tools that can help reconcile a graphic design to a website. Most of what we have are attempts to change how graphic designs are created so that they can be more directly transferred.

Post reply on HN