3 ms·
It's one thing to have a great repository of reusable, accessible, versioned, centrally managed and agreed components. It's quite another to have production sys
by ProxCoques 3y ago
It's one thing to have a great repository of reusable, accessible, versioned, centrally managed and agreed components. It's quite another to have production systems actually using that repository, unless the DS came before building the systems.
So I'd be interested to see how this might get over the hurdle of being retrofitted into legacy systems. So many design systems I've encountered are effectively fictions: great ideas being maintained in theory, but it's next to impossible to commit the necessary operating costs to getting them into production. So the sites and apps you see may look like they're using a DS, but many of those components are "impostors" not being managed in the DS at all.
- janeerie 3y agoHaving worked on a couple of these projects, the new design system is being implemented as new systems are built or when upgrading tech on older systems. I don't think anybody is doing an overhaul just to implement the design system, but as part of a new design or redesign, it's quite useful.
- ProxCoques 3y agoIndeed, certainly nobody is doing an overhaul just to implement the design system, because the business case for that (unfortunately) is too hard to make. And obviously, if you've got a DS and building some new front end from scratch then you're going to use it. But in my experience, when upgrading tech or introducing new features that involve cracking open the FE codebase, there is extreme pressure to do the cheapest/fastest thing. If a product manager asks his team how long it would take to do X, then how long it would take to do it AND update various things to use the DS in the process, that extra work seldom gets signed off. "No extra opex on my budget".