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?
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://tr.designtokens.org/format/