Live data from Hacker News

Design Token-Based UI Architecture

martinfowler.com

41–50 of 143 posts

Re: Design Token-Based UI Architecture

#41
post #27
post #23

Earlier quoted context omitted.

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

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

Like did you integrate into figma, or write a gui for them, or something else?

Re: Design Token-Based UI Architecture

#43
Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs:

1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code.

2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast.

3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages.

Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices).

I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers!

UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before?

Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers.

The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.

Re: Design Token-Based UI Architecture

#44
post #30

Earlier quoted context omitted.

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

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

Re: Design Token-Based UI Architecture

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

Can you explain the challenges in standardizing this? I don't mean to say it's simple, but curious which parts were easy to standardize and which part are most contentious.

I appreciate the standardization efforts here so thanks! So I've been working on an accessible color palette creation tool (https://inclusivecolors.com/) and wanted to add export formats that were easy to import into other tools.

For Figma, amazingly there doesn't seem to be any official/standard way to import variables yet, and instead lots of semi working/broken/abandoned import plugins that support different formats. I ended up adding DTCG, Style Dictionary, and CSS export so the user had some options to try different Figma plugins.

It would have been great if there was a single well supported format that was reliable to use here, instead of having to code several export formats that are all roughly the same. Do you know if Figma will adopt DTCG?

Re: Design Token-Based UI Architecture

#46
We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo. We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects.

Everything was working great until the designers decided the existing tokens were insufficient, and new designers joined who simply chose not to use them (because... reasons).

My point is that tokens work well when there is full alignment between the design and engineering teams. However, it requires extra effort from both sides to consistently "follow the rules".

[1] - https://tokens.studio/plugin

[2] - https://amzn.github.io/style-dictionary/#/

Re: Design Token-Based UI Architecture

#47
post #46

We use Tokens Studio Figma plugin [1] to export the tokens that the designers defined to a github repo. We have a few front end projects that consume them - one is sass based, the others are emotion/theme-ui and we have different style dictionary[2] scripts that transform the source tokens for the relevant projects. Everything was working great until the designers decided the existing tokens were insufficient, and ne…

Of course. If you don't design your system right and enforce consistency it will be a mess. That's programming and pretty much engineering in a nutshell.

Re: Design Token-Based UI Architecture

#49
post #26

Earlier quoted context omitted.

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

Why call it tokens instead of variables?

Re: Design Token-Based UI Architecture

#50

Earlier quoted context omitted.

What you describe sounds like a config dictionary. What benefit does it offer to standardize that for this very special (and probably rare) use case? I don't know many companies that could actually have the problem of scaling a design change up to 50 apps, because most don't have 50 apps. But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for…

It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me. UI design decisions are rarely artifacts in any deployment pipeline, so more power to the design team then, which is a good thing imho. I know many companies (enterprises) that actually have this problem of scaling a design change up to 50 apps. These apps are either new products, rewritten parts, outdated "leg…

> It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me.

I wish you were responsible for writing the article. This is a much better explanation.

Post reply on HN