[starbugs]

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

[whilenot-dev]

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

[andybak]

> It sounds like a config dictionary with a continuous pipeline and good integration into design tools to me.

I wish you were responsible for writing the article. This is a much better explanation.

[kaelig]

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.

[starbugs]

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

[kaelig]

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.

[baq]

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