CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.
I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise that’s done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and there’s tons of stakeholders you have to align due to the risk to the brand.
Front end engineers love to opine over amazingly flexible design systems, though.
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.
Yes, and also design changes never seem to align precisely with the parameters you anticipated at the beginning. I.e., you don’t just need to update one color variable, you need to update that color AND add a secondary accent color AND change the positioning of the logo with respect to the company name, etc.
> CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve.
I think it's more that design tools didn't used to support constants like this. Now tools like Figma do, designers are taking advantage of them and figuring out how to best to share constants/tokens with developers.
Most web design is probably done by designers and not developers too, so it's not likely to be CSS variables (which have been available in CSS tooling like Sass for ages) that is driving this. I agree it doesn't need to be over complicated though.
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.
> This is an organizational tool that increases in value as a multi-platform company grows.
That sounds impressive enough for the UX sales presentation. Meanwhile, how is it any different from "don't just use numbers, use an agreed-upon set of constants"?
> 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.
Awesome. And I assume all contrast issues fix themselves? So do color clashes? No? Designers still need to consider their change in context? So, again, how is it different from a set of agreed-upon constants?
CSS variables and derived values are a way to implement those constants. Not the only one, but a decent one. Yes, you need to properly resolve dependencies/propagate values, but you need to do that with any other implementation as well.
Sure, call it design tokens instead of constants - but is there any difference? I'm really trying to understand how this is contributing anything on top of symbolic referents. Something that at least on the engineering side is well known since before the infamous "should the value of pi change" manual entry.
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.
I suspect commenters already don't quite get the point of design systems in the first place, this UI architecture idea goes several steps beyond that. Design systems are already really hard to pull off depending on the people involved, any effort at systematizing that approach are very well worth it, but is going to be met with opposition.
I suspect if you wrote about atomic design[1] for example you would get similar comments.
Also here[2] is an example of a design system to better understand how to extrapolate the "brand color" example.
> 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".
> 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.
It won't be just a single color either, but a whole palette for them. It's not practical to do a search/replace of color hexes across all designs and code, because it can depend on context which color is appropriate to use where, especially for accessibility.
It's also the norm I would say for startups and small companies to launch with minimal/good-enough branding (often with poor color contrast for the main brand colors because people love bright colors on white), and then they change/refine it later when it's more important.
Not saying you need design tokens at all stages, but brands do evolve.
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.
M3 is an upgrade but even the "header carousel" component there had me straight up pause and study all the ways it's terrible
From the ripple effect that overflows depending on how wide the text underneath is.
The "back button" which is actually for going from one section to the next
And the way it behaves as I click from section to section using those buttons is "top tier jank" for the lack of a better term
The way it also randomly seems to align or not align the currently selected heading resulting in weird clipping of text that just looks confusing and broken.
The shadow indicating the elevation chance as it goes sticky also looks and feels straight out of Windows 95
Why can't Google just make an aesthetically pleasing UI? It almost feels like Apple and the "modern SaaS template ala WorkOS" guys stole the only two good looking directions for modern UI aesthetics and now Google is stuck pushing along their hideous (but identifiable!) aesthetic along side them.
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.
But what you need to replace is semantic strings, which "computers" are really bad at finding, and programmers, thinking it's easy, are really bad at adding
if this is the first time you heard that term then you will be hopelessly lost, but these concepts are a decade old by now and used by UI teams in every medium/major company in the world. It's well established terminology, if people never heard about it before they should question the validity of their opinions on the matter.
> 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.
Perhaps I'm missing something, but Bootstrap does support this, doesn't it?
The point of design tokens is that they sit above your framework and library choices, so it's not possible for bootstrap to solve this as it's a down-stream library. Bootstrap is a consumer of design tokens in that they might be fed into bootstraps css variable system. But in a design token system you wouldn't use bootstrap as a source of truth for these tokens, you want something more flexible and programatically portable than CSS.
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.
Cool, so we establish that the likes of Bootstrap and Sass already solve this problem for the web.
> They don't solve the interop problem for Figma/Sketch/Framer
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?
You're trying to refer to platforms/OSes, aren't you? Do you think it makes any sense to bundle everything together? Those who work on iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars would certainly look at you perplexed just for suggesting that specifying color schemes even registers as a concern in the whole cross-platform discussion.
> 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.
It seems like there are some good ideas in here but the terminology is utterly alien to me. Not sure if it's me or this is just deeply wrapped in consulting jargon.
The core idea seems to be putting visual parameters in a single place that can be shared across platforms. That way you can tweak the design everywhere without having to edit N different platform-specific implementations.
It's because you can sell "Token-Based UI Architecture" for $1,000 an hour, but you can't sell "CSS variables", so they try to make it sound as complex as possible.
The term “design token” seems to have been invented at Salesforce as part of their design system a decade ago. Apparently the “token” part is the value of a configuration property and at minimum you need a key-value pair defining the property. There is an ecosystem where configuration files are used to exchange data between design tools for standardizing things like colors.
It’s kind of wild that this whole ecosystem evolved without previously coming up much on Hacker News, but that’s just how it goes. Inventing jargon isn’t bad. There is certainly a lot of programming jargon that we inflict on others.
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them into the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake.
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
New jargon lets you avoid overloading existing terms and it adds specificity.
When someone says design token, you know they're talking about this. They don't have to say "variables" or "constants" + extra explanation that narrows the reference to the TFA concept every time they want to refer to the concept.
We do this so often in programming that you take it for granted. You're using dozens of words that weren't used 10 years ago.
Hydration is a good example of one of those words in the webdev space.
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
light/dark mode as user setting is a variable, current viewport too. But the dark primary button background color and light primary button background color are constants in a design system.
> "user avatar background" may be defined by the user themselves
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.
> 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.
Yeah... auth tokens, resource tokens, rate limiting tokens, monetary tokens, LLM tokens, parser tokens, etc... you might as well name it "thing". It's about as bad as "node".
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.
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.
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 design parameters.
If you want such a hard dependency and kind of automation in this case is another question. I could imagine a lot of special cases where this would cause another set of issues with, e.g., accountability (which part of the codebase belongs to which maintainer and so on).
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 "legacy", or stuff that has been outsourced previously. Now these companies are in demand for "rebranding for the digital age". It all depends on how well design tokens integrate into those situations and its used design tools.
A problem I see is also that such enterprises rarely make use of a better ratio than having 2 designers for the whole company, which then, in turn, suffer from opinion overload by various stakeholders. The UI design process produces visual artifacts and good designs always feel simple. I seen it various times that stakeholders therefor wrongly conclude that the design process must be simple, and that's the never ending circle of a designers life. That brings me to another concern...
Since design tokens open up the automation possibilities with specific design pipelines that might find their way into a deployment to production, and it isn't uncommon stakeholder-thinking that "designs are easy" - all that while LLMs are on the rise, mind you - I can also imagine some kind of horror scenarios finally playing out, especially when changes aren't well tested (responsive design, accessibility etc.).
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.
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.
> But I would guess that those who actually have to solve this problem are staffed properly to implement a shared configuration for design parameters
This is never a priority, so it never gets done. When it suddenly becomes a priority, you get all the problems described above.
A large company doesn’t mean there’s a team to handle everything. It just means there’s a lot more people to talk to before you can start work on anything.
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.
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.
I don't get why the marketing speak is necessary. I also think it's detrimental to what we've built as engineers. Please stop. It's neither a token nor a hook, it's a simple variable.
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.
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?
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?
> 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.
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.
> 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?
We use a Figma plugin called Tokens Studio, which stores its source of truth a (a big JSON file) in our github repo. Designers manage all of the token values there and push updates to a branch and create their own pull requests which developers then do a minimal review on. Long story short, the tokens are converted to CSS variables, which we consume in our styles (we use Vanilla Extract which makes this very nice). The tokens in Token Studio can also be used in the Figma designs, but its a little clunky.
Figma recently launched their own native solution (called Figma Variables) which is more slick and better integrates into the design tooling, but it is mostly locked behind an enterprise-level plan (which lots of folks aren't happy about)
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/draft-pbryan-zyp-json-ref-01... — and just in case, we ran this syntax past Ben Hutton (inventor of JSON Schema) to ensure we weren't doing anything silly.
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.
I was super happy learning about design tokens a couple of years back, and eager to use them, but since then my enthusiasm fell as it seemed to "never get there". Figma implemented something which is okay-ish, but completely useless for our needs, while Penpot announced their collab efforts and then radio silence for roughly 2 years now.
I could be out of the loop a bit, but I see that this spec is also still a draft. As somone who'd love to evangelize and implement design tokens internally, when do you see this stepping into the spotlight in a meaningful way? Is there a roadmap of some kind that's available to the public?
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.
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.
I'm sorry, you wrote words but they don't say anything. They sound like machine-generated nonsense.
Can you actually provide a concrete example of a concrete problem you want to solve with the token-based UI initiative? Write your answer following the STAR format, and leave the buzzword bingo out.
If you cannot explain your problem then this is a very clear tell that it might not exist at all.
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.
Great answer. In your scenarios, let's say OrangeCorp has their 'brand-orange' color token. They've defined it as the hexadecimal `#FFA500`.
Engineer Bob implements it as `hsl(39, 100%, 50%)` in a web project because the loading state requires shifting the color values, and he has a library that works with HSL but doesn't work hex.
What do you store for the source of truth? Are we just storing the hex value, and deriving translations from that? Or are we storing 'brand-orange' with a map of "hex: FFA500" and "HSL: 39, 100, 50"? Does the specification have an opinion?
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.
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.
The thread reminded me of exactly designtokens.org. We've made this part of our design vertical. The question is how do we get engineering utilizing frameworks like MUI to implement this?
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 styling over the onslaught of classes in i.e. tailwind.
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 consistent and without distracting incidental variation in hue.
[0] When it comes to CSS—of course, design tokens reside on another layer of abstraction, not tied to any particular implementation.
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?
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".
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.
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.
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.
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.
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.
> 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
Yes but also be aware of systems (or lack of) that people deliver crap fast (which is only better than delivering crap slowly).
This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element".
Here is my slightly edited comment from below:
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.
“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”.
(The term “variable” may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.)
As an old-school designer, I didn’t like the term at first, but to be honest it is winning me.
I was taught design in terms of design models and design systems, so there was not much of a leap to “design token” as referring to a building block.
I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are tied. At the same time, I can see how even while using tokens it is entirely possible to design a bad interface. However, I also see value of them when it comes to maintaining consistent and intuitive UIs.
> I also see value of them when it comes to maintaining consistent and intuitive UIs
Absolutely. It's like the proper legacy of the GoF's "Design Patterns" book, whose lack of importance and acceptance has bewildered me for close on 30yrs now. Of course, it also means I have rich fields to till for my own work, so bwahaha :-)
[Note that the actual design patterns described in their book are not the important part; their understanding that we must implement software using patterns is their most important concept.]
You can already imagine OS vendors publishing their design tokens to let you "easily" integrate your applications even if not using their UI libraries.
I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
Some of the examples look a lot like tailwind. Was this inspired by the that or is tailwind actually attempting to implement some of these concepts? Anyway, I'm using tailwind more and more and I am liking that.
Not hard coding colors, margins, etc. is definitely a nice thing. And being able to reuse definitions for those across multiple projects, software stacks, frameworks, design tools, etc. would be nice as well. Does something like that exist at all? Because the last thing companies should be doing is building a lot of internal crap to support this probably.
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 but the cloud changed everything" - no someone made the cloud more complicated than it needed/needs to be and thanks to ZIRP, companies just kept hiring DevOps 'engineers'.
I've seen this multiple times: Management looks at this circus and goes "Let's make all each dev team handle their own DevOps crap." Meanwhile, they're telling the actual DevOps engineers to go back to focusing on ops. What was even the point of this whole transformation if we're just creating more specialists and dumping more complexity on developers' plate?
The whole thing has basically turned into its own monster that needs constant feeding. We didn't need all this overhead before, but here we are, drowning in YAML and dealing with infrastructure that's way more complex than the actual problems we're trying to solve.
I can't wait for Design Token Engineers to become a thing /s
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.
In your 'about', you have worked with/at well-respected tech companies. I suspect they had significant investment in their DevOps teams and that has not been my experience at large non-tech companies in my career. Our differing experiences make sense when thinking about it in that context.
In one sentence: Design tokens are a standardized way of defining constants used in a design system.
If most developers haven't heard of them, it's because most developers don't create design systems. Even when you use a design system, the actual use of design tokens would likely be hidden.
yeah, still don't get what is all the fuzz is about. defining symbols systematically (e.g. with some hierarchy) and having constants mapping symbols to values - all is a no-brainer
Well you could distill most "modern" methods to one subtitle of The Mythical Man-Month book: Plan the system for change.
TDD, DDD, extreme programming etc come from the same observation: the client does not know their needs. Even if they do, those could change. So you want to build systems which are easy to change. And we still get thousands of pages published in the form of books or blog post for something written and explained in a book almost 50 years ago.
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.
Not true. This kind of comment is exactly why most of us flock to this site. It's important to point out when the emperor wears no clothes. There's already an army of self-promotipn types forcing this nonsense onto everyone.
I mean it's kinda jargony and yeah kinda like #define, but I think the idea is specifying a namespace and specific types with a focus on UI/UX design.
In C you'd maybe do it by prefixing all the relevant macros with DESIGN_foo but I think part of the goal of this is outlining all the potential "Foo"s and utilizing it to maintain consistency across a large organization
As a dev working with designers who have embraced the Figma token generation, I have to say the whole effort seems ill-conceived.
The sheer amount of problems faced with tokens going missing, unclear rationales, endless updates and follow-up, coordination, etc makes me yearn for days where designers dropped a design file and devs figured out if tokenizing made sense.
Plus, tokens are only as good as the deeper design decisions, but that abstraction always has consequences. Not to mention the performance impact of css vars.
Again, it feels as if the idea has been stretched so designers can change code tokens at will, but to do this would require an insane amount of tokenization that in a sufficiently large code base would become unmanageable. Our latest token count is nearing 5k unique tokens, and that only covers maybe 2% of custom css we have to use to achieve the desired outcome. For me, it’s a net negative.
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.
Design-first thinking with tokens is a game-changer for an org building a product that needs to adapt to multiple clients. It's still useful for a singularly-branded product just for separation-of-concerns reasons, but maybe less useful.
Design tokens aren't concerned with implementation. (CSS vars, constants, etc.). Design tokens are an abstraction for standardizing and communicating the values in your design system, regardless of where they show up. Yes, you might implement your design tokens as CSS variables, but not necessarily.
The NL Design System (https://www.nldesignsystem.nl/) is a project funded by the Dutch government which works with Design Tokens. This way government agencies and municipalities can share components but still retain their own look and feel.
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.
I'm all for simplifying the indecipherable, but this is a case where things need to be made as simple as possible, but not simpler. Design systems determine how everything looks and feels, and this means specifying a number of things together, such as what colors a button has, how it looks when pressed and hovered, how dialogs look, what is dark mode or light mode, etc. Calling this "constants" is simplistic and a sign you are commenting on problems you know nothing about.
And now there's a layer of design consultants who sell complicated ways to think about organizing constants and computing derived values, and it's not in their interest to make it look any simpler.