And if that’s not the goal, what is the goal?
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.
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?
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)
How do Design Tokens along with the article's identification of "Translation Tools" differ from existing template-based code generation techniques?
In other words, what problems do Design Tokens solve which cannot be satisfied with sh[0] and sed[1]?
0 - https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sekti...
1 - https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sekt...
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.
What does this mean?
Do you have a concrete example of where this actually solves a real problem? And what problem would that be?
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.
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).
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.).
I wish you were responsible for writing the article. This is a much better explanation.
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.
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.
I would argue that it's not in anyone's interest to add such kind of complexity when it's not needed.
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.
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.
> styling hooks
You mean variables.
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.
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.
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
The spec is acting just like how CSS doesn't tell you how to name and nest classes.
I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!
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
> "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.
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.
Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".
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.
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.
I've only ever seen $ used before with meta properties that work across all schemas like the $ref you mentioned and $schema.
That said, there definitely are other valid ways to solve it.
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?
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?
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.
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.
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.
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.
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.
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?
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.
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/