I agree here, especially on the danger of "let's make some components!" while ignoring the YAGNI principle -- ya ain't gonna need it. Build components where they are needed and wanted...and NOT with grandiose visions of "if we build it they will come...and immediately adopt everything and the platform consistency issues will be solved" (which seemed to be the mantra of some teams I've observed.

Yep, YAGNI (you ain't gonna need it) applies to design systems every bit as much as it applies to code. Dan Mall's advice here is great: don't start at the abstract level, start at the extract level. Make a few pilot screens, pull out the common elements for reuse, and don't try to cover every use case yet. As you work through more pilots, you expand components to handle the cases you actually run into.

Why does "if we build it they will come" go sideways? Largely the maintenance math. Ten design components don't create ten relationships, they create forty-five potential interaction points to consider. So every speculative component multiplies complexity, and that's why every design system keeps spiraling out of control. I've lived this one. At Yahoo we had a whole team devoted to the pattern library, five designers and three developers, and it never stayed up to date.

There's a second problem with building ahead of need: you lose the context. When we did the Yahoo patterns, the "in context" part was the bulk of the work: when a solution makes sense, why, and where not to use it. A component nobody has used yet can't have that, because nobody knows the situations it'll show up in. So you end up documenting what it looks like in gray instead of when it helps.

And the "immediate adoption solves platform consistency" hope skips the fact that consistency isn't a good barometer for success. Plenty of very consistent products are still bad.

So before adding that next component, ask whether it'll make up for its maintenance costs, or whether you can simplify the design to be more like the rest of the UI instead of requiring new concepts or components. Systems pulled out of real screens tend to get adopted, because the teams building those screens were already using them.