A couple of weeks back, Ethan Marcotte joined us at the Boston WordPress meetup and gave a talk titled “The Design Systems Between Us” (video embedded below).

As one would expect, it was a thoughtful exploration, parts of which are still looping in my brain.

What are we to do with design systems in the age of AI? How can we get not just increased output and consistency but actually improved results for users? Can we make design better, not just make more design?

How did we get here?

When we started building digital design systems (over a decade ago), the promised outcomes were consistency, velocity, and improved collaboration (between design and development teams, and across multiple teams). In larger organizations with multiple design and development teams, access to a design system library (which captured both the look of different components but also their realization in code) would surely be more effective than each rolling their own.

So why is it that many design and development teams are experiencing design system fatigue? Why do so many designers feel that design systems have changed their work experience but not necessarily improved it?

One of the immediate issues every design system project runs into is what we might call component sprawl: an individual or team changes or forks a component—often, if not always, for good reason—and in the process that change either doesn’t make its way into the system or does, but in an unclear way. The system ends up with gaps between the standard and the way it is actually used. There are solutions with improved communications flow and collaboration, and devops thinking about how code changes flow upstream and downstream, but these address only a part of the problem.

The deeper issue, in my reading of what Ethan’s discussing as “visibility” is the lack of the why: what the components in a design system (as code and as design artifacts) leave out is the set of reasons why decisions were made. You get the residue and artifacts of the process that lead to those decisions, but not the active thinking part. You know what the component looks like (and some of how it behaves, in the js/css sense) but not why it is the way it is.

(To be fair some people build design systems with robust documentation about why—what the standards are that the system is meant to uphold—but does anyone read those standards, and if so are they authorized to make local changes consistent with that why?).

Prescriptiveness Limits Flexibility

Digital design systems are not our first go at trying to understand how patterns might be useful in designing and building. In the classic book A Pattern Language, Alexander et al. identify a series patterns as “solutions to specific problems” at the scale of towns and buildings. This catalogue of patterns would then be used by each builder as adapted to the site on which they were building.

The key challenge is how to balance the universality of the pattern and the specificity of the local solution. What makes it a pattern is that it tends toward universal applicability; what makes it a good design solution in a particular site is local and specific. For Alexander et al. (as for Marcotte) the answer is to empower the user of the system, the builder:

A pattern would be shaped by the builder, who knew best how to use it.

In the design systems most teams have built, the pattern is not shaped but used: imported and deployed, not evaluated and adapted. It’s almost as though the system was designed to enable programmatic generation of new experiences without the need for any thought at all by the team designing and deploying them. (Queue the AI).

Marcotte shared some examples of more flexible design systems, which better achieve the balance between flexible and prescriptive, and empower the builder (and designer) actually charged with creating implementations or instances of the system to make more active choices. He concluded by calling for more focus on the people and processes in the system, rather than just the components.

A design system is more than its patterns.

It’s also the way people work with those patterns.

If we can reinsert the active designer into the process and consistently create visibility and awareness as to the principles the system is designed to represent, we’ll undoubtedly create more effective pattern usage and relieve some of the design system strain Marcotte accurately describes.

I think of this as the “design-as-a-verb” part of design systems as opposed to the “design-as-a-noun” part: the activities, questions, contexts, and decision making, not the artifacts and the code. All it requires is people in the loop.

AI Has Entered the Chat

The challenge, of course, is that this is approach requires reinserting active human decision making into the system at exactly the moment many large teams are looking to their design system for a different purpose: providing the raw material for the AI to use to create more efficient outputs without need for human designers.

If the original promise of design systems was consistency, velocity, and improved collaboration among the human participants in digital implementation, the promise seen by many in design systems in 2026 is that they can guide/constrain/enable AI implementations. Give the LLM of your choice access to the component library (or evaluate its output against compliance with the design system) and you don’t need those pesky human designers (and their questions about whether this pattern fits this problem) at all.

One possible way to combine the power of AI with human decision making (discernment, taste, contextual awareness, judgement) would be to empower the human custodian / overseer of the design system, as an orchestrator of the work of the AI. But again this sinks quickly in practice into becoming the design system police.

A foolish consistency is the hobgoblin of little minds adored by little statesmen and philosophers and divines – Emerson

In many organizations the owner of the design system already find themselves transformed into the compliance department: ensuring the consistent use of the design assets and code, but with little opportunity to be part of the conversation about why certain patterns make sense (or more importantly, when they do not). While a certain narrow definition of consistency might result, it feels like a pyrrhic victory in that it doesn’t necessarily improve the actual design or function of the things built this way.

How Should We Proceed?

If there’s an optimistic read here, it’s that the increased efficiency and higher output volume that AI can deliver can be matched with a greater amount of time spent by the humans in the discussion and process. Rather than managing components, and checking for consistent usage of the components, design system managers can be engaged more directly in what is being built and why. (Maybe they could actually talk to users of the systems? Shocking, I know).

Remove the friction of managing all the code bits and the drudgery of writing css, and instead free up those minds to focus on context, judgement, and outcomes in the truer sense: whether the way were using patterns is making the experiences better for the users. Do more designing, in the active verb sense, and less producing design outputs in the noun sense.

So far, the prevalence of AI slop does not make me overly optimistic many organizations will choose that path, at least in the short run.