Hacker News Reader

Comment by kaelig | Hacker News Reader

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

View on HN

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

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

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

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.

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

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.

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

> or perhaps a brand refresh.

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.

"it depends"

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.

> design tokens

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

It goes beyond variables. At the minimum it's a name and a static or dynamic value, but it can also contain metadata, transforms, private/public attributes, formatting constraints...

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.

How about instead we just start making companies smaller but have more of them?

The UNIX philosophy doesn't play well with the ego of ones business, unfortunately.

Reply on news.ycombinator.com