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.
It's not too different, as the concept was heavily influenced by localization libraries.
That said they're not always constants. A design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can apply at runtime or at build time depending on the use-case.
Bootstrap and Sass are for the web. They don't solve the interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars and what have you.
And that's not even accounting for web styling solutions that don't use CSS variables.
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.
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
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?
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).
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.
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.
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.
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.