Design Token-Based UI Architecture
martinfowler.com
martinfowler.com
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.
Front end engineers love to opine over amazingly flexible design systems, though.
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.
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.
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 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".
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.
And there's an important runtime aspect when it comes to theming, so it's not just about finding/replacing hardcoded values.
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.
Facebook updated their main brand blue and other colors in 2023, partly for accessibility: https://design.facebook.com/stories/redefining-facebooks-bra...
Wise also had a rebranding with accessibility in mind: https://the-brandidentity.com/interview/how-the-ragged-edge-...
Figma recently changed their colors too: https://www.figma.com/blog/figma-on-figma-evolving-our-visua...
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.
Perhaps I'm missing something, but Bootstrap does support this, doesn't it?
https://getbootstrap.com/docs/5.2/customize/css-variables/
Please explain why you feel this usecase hasn't already been supported for years.
Also, other tools such as sass also support this feature.
https://sass-lang.com/documentation/variables/
Can you elaborate why you think this problem isn't a solved problem?
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?
> iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars
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.
>
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.
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.
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 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.
[1] https://atomicdesign.bradfrost.com/chapter-1/ [2] https://atlassian.design/components/tokens/all-tokens
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.
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.
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.
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.
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).
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.
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.
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!
Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".
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.
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.
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)
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.
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.
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.
Generally UI is built around a singular look and feel at a given point in time. Trends change, people change, ideas and features change.
You eventually end up with a rebranding and along with that some sort of UI refactoring.
This approach is incredibly valuable when building something that won't change drastically when you are changing those tokens.
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?
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".
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.
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.
+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.
Yes but also be aware of systems (or lack of) that people deliver crap fast (which is only better than delivering crap slowly).
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.
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.
(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.)
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.
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.]
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.
Heaven help us. Hope this dies a quick death.
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
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.
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.
Material Design uses them. https://m3.material.io/foundations/design-tokens/overview
Fluent UI uses them. https://fluent2.microsoft.design/design-tokens
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.
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.
Yet who does things like that?
Web developers have tendency to do not innovate themselves, they need to be told by $tech_influencer that you can create your own custom solution
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
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.
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.
https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
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.
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.
There should be some research into how many code bases have been ruined by these panacea peddlers.
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.
like domain specific language