kaelig

It goes beyond variables. At the minimum it's a name and a static or dynamic value, but it can also contain metadata, transforms, private/public attributes, formatting constraints...

You may not be aware (and 10 years late in trying to stop this), but this name has been very well received in the web design industry and frontend world and helps us build a community of craft to solve similar problems together.. so it looks like it's here to stay.

But the dark primary button background color and light primary button background color are constants in a design system.

They are not necessarily constants, and _could_ point to a theme's value, or even be generated on the fly.

Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user preference and its lifecycle has little to do with the design architecture of the product.

That's a choice you can absolutely make for your use-case.

A design token _can_ be a named design property with a dynamic value, and sometimes a fallback. User preferences _can_ feed values into existing tokens.

The important part is that design and engineering are speaking the same language when referring to these – you're free to tokenize these or not.

Thank you for sharing – and good luck, as this is a tough situation to be in.

Some teams neglect to consider the entire lifecycle of a token and introduce too many, too early. They can bring a ton of value, but it has to be weighed against the learning curve and maintenance burden.

The industry is full of very eager folks who get into design systems but were never on the receiving end of one, and who sometimes overdo it.

Like I said in another comment: "systems people will systematize".

Design tokens are not the cure nor the problem, but like any approach, it can go wrong when taken too far or is owned by folks too siloed from engineering to realize their full power.

The "fun" part with HSL is that RGB->HSL->RGB conversion doesn't always land back on the initial value (and that's why I discourage using HSL altogether).

In orgs without design tokens, I forgot to mention there's also number of folks using the color picker from their OS to grab what they think will be the right color, sometimes even on lossy images like a PNG, JPG, GIF... and that's how you end up with the 50 shades of blue.

Bootstrap and Sass already solve this problem for the web.

In a vacuum, sure. But products aren't all built in a web-centric vacuum.

That's irrelevant, isn't it? I mean, do you run apps straight out of Sigma/Sketch/Framer? Do you also think it's reasonable to call out Photoshop/Gimp/MSPaint?

Figma/Sketch/Framer are design and prototyping tools. They are _very_ relevant in how we build products. The back-and-forth between design and engineering leads to better outcomes if both sides speak the same language, and their tools allow them to do so.

(Photoshop/Gimp/MSPaint aren't so relevant un product design)

Do you think it makes any sense to bundle everything together?

Not everything. You generally want folks using your products across iOS, their car, their TV, and a web browser have a coherent experience. This doesn't mean that everything needs to look exactly the same. It means that key design decisions can be distributed across the board.

They can be constants, but not always: a design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can happen at runtime or at build time depending on the use-case.

Examples: - "primary button background color" may be different across light and dark mode - "header height" can vary across small and large viewports - "user avatar background" may be defined by the user themselves - "brand primary" may change for re-usable UI components based on the brand they're used for

It's not too different, as the concept was heavily influenced by localization libraries.

That said they're not always constants. A design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can apply at runtime or at build time depending on the use-case.

Bootstrap and Sass are for the web. They don't solve the interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars and what have you.

And that's not even accounting for web styling solutions that don't use CSS variables.

You can try automating search/replace on hex/hsl/rgb values across all your codebases, but targeting "primary button backgrounds on hover" is only possible with some more advanced tooling in place.

And there's an important runtime aspect when it comes to theming, so it's not just about finding/replacing hardcoded values.

They sound like machine-generated nonsense.

Fair! Perhaps I should have used an LLM to de-bullshitify my message...

Let's walk through a common scenario:

Design tool A has brand colors coded in hexadecimal, those have no name, they're just hex values.

Design tool B has colors named in CamelCase, values in HSL.

Codebases A, B, C have colors in RGB, named the same as in Design Tool B.

Codebase D has colors in Hex8, with their own naming convention.

100s of developers copy/paste values from old and new designs over the span of several years.

Codebases now have 50 shades of the "primary blue" scattered around. Now user experience feels disjointed at best, confusing and hostile at worst.

Engineering design collaboration is tough as no two tools and teams speak the same "design language".

Say a team wants to implement a new feature across multiple codebases where styling and naming are all different.

Lacks of re-use and poor communication leads to entropy, which leads to poor quality and slower delivery.

Design tokens are the interoperable layer that help define a common language across people and tools and improve what I described above. (for those familiar with DDD, there are a lot of similarities)

The spec itself is baking this into the entire toolchain so it's available to teams by default, without requiring as much custom tooling.

PS: the scenario above may seem extreme to some, but it's _extremely_ common at medium to large companies with no established design/engineering processes.

Joke aside, there are truly valid reasons why you'd want to change a single color across dozens of codebases, for what can amount to tens of thousands of occurrences. For example: adjusting link color contrast for accessibility compliance.

Salesforce (where the term "design tokens" was coined) is akin to an operating system for the web, with its own app ecosystem. Developers building Salesforce apps can blend into the Salesforce ecosystem thanks to their design system and design tokens.

And I recommend reading https://m3.material.io/foundations/design-tokens/overview to see how Google allows Android app developers to build incredibly expressive and user-personalizable UIs using design tokens.

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?

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.

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.

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.

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.

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.

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

It's certainly been a longer journey than I'd anticipated to get to a "V1", but the current snapshot of the spec does have good penetration, allowing us to see what works and what doesn't in the wild.

The main areas that need work for us to publish a "V1" are: - colors (it's almost there, we almost entirely reworked this part of the spec in depth over the past 2 years) - "modes" and "themes": the Tokens Studio team proposed the "resolvers" module, based on their user research and empiric evidence that it solves theming needs. We're editing it right now. Once it's in the spec, Figma will be in a position to support the spec natively.

Say more

For context, this name was coined 10 years ago, before the crypto/blockchain craze.

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.

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!

This is fair, I've also seen design systems grow in complexity. Sometimes for good reasons, but also because "design systems professionals will... systematize".

That said, it's not just about "updatability" of systems, it's in great part about scaling a design language across multiple surfaces, products, modes, locales, and sometimes even multiple brands.

The orthogonal complexity of design decisions can be pretty high, and does requires powerful interoperable tooling to handle. Hence the need for this methodology and a spec.

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 little incentive for teams to prioritize it... But in aggregate, UI inconsistencies bring death by a thousand papercuts.

Companies with design infrastructure teams and mature design cultures have automations in place. The goal is to bring such power even to those without design infra teams and early on their design maturity journey.

There are multiple ways to solve this, we've explored a few and we found that clearly differentiating user inputs from the spec keys was the right way to go for this use-case and our audience.

That said, there definitely are other valid ways to solve it.

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.

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.

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.

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.