(Credit to Sara Wachter-Boettcher, whose “We don’t need more content, we need content that does more” is imprinted in my brain).

I’ve got a ton of ideas from Ethan Marcotte‘s talk at the Boston WordPress meetup earlier this week – will share the video when it is ready. He explored what’s gone well with Design Systems (lots of people have made them) and what’s gone less well (lack of visibility, design system fatigue, fragmentation, component sprawl).

It’s had me reflecting on what we intended for Design Systems to deliver versus what they have delivered.

My “hot take” (three days later) is that perhaps what Design Systems have produced is higher output rather than improved quality: more design, not better design.

The design-system-as-component-repository approach has meant that success gets measured in the number of components designed, or how much those components get used. It’s perilously close to “lines of html and css written” as a metric.

What we seem to have lost (as Ethan pointed out) is the active design-as-a-verb part of the equation: the principles and aspirations that drove the decisions that the output reified into code.

If we don’t know—by which I mean understand deeply across the team who are consuming and deploying the components—why the components work and look the way they do we inevitably use them in ways that don’t live up to their promise.

Overlay this with the current pressure to AI-all-the-things and you get automations using design system components *correctly* (in the letter-of-the-law sense) without using them *appropriately* (or dare I say *wisely*?)

Part of the answer (as it usually is) is better documentation and active conversation across the folks using the design system (as well as those driving the content the design system is intended to express/convey). Is it possible to empower smarter decision making by Design System users that better respects the intent behind components—what pattern / use case they were intended for and why the choices were made a certain way—without slowing down a large team operating at scale?