31–40 of 143 posts
Earlier quoted context omitted.
The fuzz is about writing 2,000 words on a simple concept in impenetrable jargon in order to better demonstrate the thought leadership of your practice and the need for deep consultation to translate the aforementioned impenetrable jargon into simple language so mere plebes can implement the advice.
This kind of comment isn't welcome here...
Earlier quoted context omitted.
The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/format/#character-restrictions 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/dra…
You can usually do this by only being additive with the spec, and by never mixing user-defined keys and spec-defined keys in the same object. 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.
Earlier quoted context omitted.
> At a certain scale, design and brand teams need infrastructure to drive change What does this mean? Do you have a concrete example of where this actually solves a real problem? And what problem would that be?
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mo…
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).
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.
Earlier quoted context omitted.
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mo…
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…
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.
CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. 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.
Earlier quoted context omitted.
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mo…
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…
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.).
Earlier quoted context omitted.
Let's take a very atomic example, that becomes a problem at scale: say you want to change the primary button color across all your apps (for accessibility reasons, for example). If you have 50 codebases where this color is applied in many different ways (naming, color format...), it's a real struggle. You're going to waste time, miss spots, and the user experience will be inconsistent. Now imagine rolling out dark mo…
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…
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.
CSS didn't support constants and derived values for a long time, so a generation of web designers grew up thinking this is something quite difficult to achieve. 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.
I agree and was going to comment something similar: Like entropy, design systems are getting ever more complicated. This virtue of having infinitely updatable design systems is a bit lost. For most people this is an exercise that’s done extremely rarely, is difficult to advocate for because the ROI is perceived to be low, and there’s tons of stakeholders you have to align due to the risk to the brand. Front end engin…
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.
Earlier quoted context omitted.
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…
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…
I would argue that it's not in anyone's interest to add such kind of complexity when it's not needed.