Design systems PM for Figma here. What the author is saying here is correct for enterprise-scale companies. To your point where you urge for rapid iteration, if Microsoft launched a new product and needed all buttons to have a dropdown for said new product, would you update MS Word’s buttons to also have that dropdown?
Of course not, and that’s the authors point. Product teams should move and iterate faster than the core design platform. They should be free to break from it for their exploratory needs, and these platform teams shouldn’t bend over backwards to support them.
Another way I like to frame this is the following - a design systems team should support 90% of the use case needs of its products, not 100%. Adding support for that additional 10% often bloats the components and reduces usability and consumption. It’s often not worth that effort. New products are often rapidly evolving, and dwell in that 10% land quite a bit. Let them cook and experiment. If other teams end up adopting the same patterns, that’s when you bring it into the system.
This mentality, of covering over software at the edge, is how we got the first crop of 737 max crashes. Bad software, shitty UI and a go fast culture. Its how were so capable of evolving dark patterns quickly... product creep mentality has trained the user base to go go go and not think.
And the costs happen at the other end: it's the mental workload that happens when check boxes are toggles now.
You can frame this however you want. In most cases it's unqualified people making expedient decisions that are just confusing to users outside the bubble of tech and PM that they live in. The people who are developing these projects keep jamming AI into everything... it doest matter that ML isnt ripe, that end users dont care, that it's not fit for purpose.
I can point to massive piles of product innovation, design and feature creep that exists solely to pad the resumes of bad UX, product and engineering teams.
Slow the fuck down and do some basic usability on your stupid idea. You might learn it sucks before it's in production further numbing your user base to your bullshit.
MS Word is dramatically different from a 737. If MS Word doesn't work quite right, people spend 5 minutes looking up a work-around, or live with not-quite-as-prettily-formatted documents. If a 737 doesn't work quite right, hundreds of people die.
Basic table-stakes for having any sort of decision-making authority at a company is understanding the context of your decisions. A word processor that tries to get everything right hasn't launched yet. A airliner that moves fast and breaks things...well, breaks things.
And you're going to say "well they should have known that..." except that you, me, the average HN reader has a different relationship with tech than Joe and Jane average public.
Another way I like to frame this is the following - a design systems team should support 90% of the use case needs of its products, not 100%. Adding support for that additional 10% often bloats the components and reduces usability and consumption. It’s often not worth that effort. New products are often rapidly evolving, and dwell in that 10% land quite a bit. Let them cook and experiment. If other teams end up adopting the same patterns, that’s when you bring it into the system.