I think you're actually more in agreement with the author than you think you are. He's not arguing against iterative development at all. Rather he's arguing t

I think you're actually more in agreement with the author than you think you are. He's not arguing against iterative development at all. Rather he's arguing that product should evolve quickly and iteratively, and the design system underlying that product should move slowly and carefully, only systematizing aspects of the design once they have a large number of motivating examples. I think some of the confusion is a misunderstanding of what design systems (and each of the layers in the authors' diagram) is. It's different from design. "Design" is "This button should be 56px wide, have 8px of padding and be colored #4590ff". "Product" is "We are are building an app to let users listen to podcasts, and we should show a list of recommended next podcasts with a button beside each to play, but default to autoplaying the next one if no user interaction happens." "Product research" is "Our users frequently listen to podcasts in the car, so they may need hands-free interaction and will want to listen to the next track without user intervention." "Visual brand" is "Across all of our products, we like to use a simple white background, with dashed-line dividers between list items and #4590ff primary call to action buttons, each of which has 8px of padding and 4px rounded corners." "Design systems" is "Across all our products, use a list whenever you have a collection of homogenous items. If the list represents an audio multimedia track, use this music icon that we have uploaded to the general library. The currently playing audio track should have a moving audio signal display to indicate its selected status." Notice the increasing level of abstraction across each of these categories. Design is rules for users. Design systems is rules for designers. And that's exactly why it should move slowly - you cannot build good rules until you have seen many instances of problems in the real world and have a chance to gather data across many instances of the pattern. In my experience, design should iterate ~daily. Product ~monthly. UXR ~quarterly. Visual brand ~annually. And design systems every 2-3 years. The differing cadence is a rough indication of how many examples of each lower level you need to build a general pattern, eg. you may have 20 or so individual design decisions to make to ship a feature, you might ship 3 features from each UX insight, you might refresh the whole product's UI roughly each year as the market changes, and you need experience from 2-3 full visual refreshes to understand what sort of patterns need to form guidance for the next generation of designers.