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.

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.

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.

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.

> 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.