Design Token-Based UI Architecture

Re:Design Token-Based UI Architecture by bradhe on Wednesday December 18, 2024 @02:32AM (#42448722)

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 engineers love to opine over amazingly flexible design systems, though.

[ Parent | on HN ]

Re:Design Token-Based UI Architecture by kaelig on Wednesday December 18, 2024 @03:06AM (#42448840)

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.

[ Parent | on HN ]

Re:Design Token-Based UI Architecture by yowzadave on Wednesday December 18, 2024 @02:01PM (#42453626)

Yes, and also design changes never seem to align precisely with the parameters you anticipated at the beginning. I.e., you don’t just need to update one color variable, you need to update that color AND add a secondary accent color AND change the positioning of the logo with respect to the company name, etc.

[ Parent | on HN ]