Your Next User Is a Machine

I've been thinking about this shift for months as I've watched the work on my team change. We're still building products for people, but the first reader of our design work is increasingly an agent drawing on our design system, patterns, and decisions to create a flow. When we give it thin context, we get a thin flow; when we give it rich context shaped by a decade of learning how people use software, that judgment carries through to the result. The work I want to name is writing the semantic layer AI needs to design well.

The machine can't read the room

Give an agent access to your component repo and it can assemble a screen with the right button colors and input spacing, yet the result can still be wrong because the machine doesn't know which pattern fits, why the team chose it, or how this flow connects to the ones that came before. Components are the vocabulary, patterns are the sentences, and flows are the paragraphs, but most design systems give teams the vocabulary without explaining what it means or when to use it.

The same gap exists in research: segments, journeys, and jobs-to-be-done often sit in slide decks and Miro boards, beyond the reach of the tools that need them. A person can look at a journey map and understand what a customer is trying to do, while an agent can't, not because it's incapable, but because we haven't written the map in a form it can use. That's the artifact worth building, and because most teams haven't started yet, there's an opportunity to shape what it becomes.

What the artifact actually looks like

Some of this is already taking shape on my team. We built a small data model with 70 or 80 annotated screen examples, each recording what made the screen work: the pattern it uses, the decision behind that pattern, and the user problem it solves. The model looks simple when you browse it, but give an agent a prompt and it can return a full layout that follows those constraints; the annotations show it what "good" looks like here instead of leaving it to guess.

Next, we want the model to work with our data structures so an agent can understand not only what a screen looks like, but also what state it represents. After that comes the frontend, followed by the decisions about hierarchy and information architecture that have often lived only in a designer's head and need to live somewhere a machine can find them.

The annotations are what make the system useful, because that's where design happens: choosing which examples to include, naming the patterns that should be canonical, and deciding what to leave out. Curating that input is how the people we're designing for become part of the machine's understanding.

Build the pattern library as agent context

The internal library we're building isn't organized around colors and buttons; it's organized around flows and organisms, such as onboarding for someone new to the product, confirmation before an action they might regret, or error recovery when they've been working on a task for twenty minutes. Each entry explains the pattern, why it works, where it can fail, and which components bring it to life.

We want the library to be easy for anyone to use. A PM building an agent-generated flow next Tuesday should be able to find the confirmation pattern and understand both when confirmations help and when they get in the way, while an agent creating a layout from a prompt can draw on the same library. The PM and the agent are using the same source, which is what a pattern library can become: a living resource that people and machines use to decide what to build, rather than just a Figma page for the design team.

There's a reasonable counterargument that Figma is already building some of these capabilities: its MCP server exposes components and tokens to agents, and the use_figma tool lets Claude Code and Cursor pull design system data into generated code. In eighteen months, the argument goes, the pattern library might write itself. But a tool can serialize a component; it can't decide which pattern fits when someone is confused or what makes onboarding work for a person who has never used a product like this. That judgment doesn't automate away, and as more of the surrounding work gets cheaper, it becomes a bigger part of the design job.

Information architecture is back, and it is for machines now

There's a serious critique of this idea: isn't this engineering, not design? Context engineering is a real discipline covering retrieval, memory, tool orchestration, and token budgets, so a design leader stepping into that space might seem to be crossing a boundary without the technical depth to back it up.

I see two different layers. Retrieval and orchestration determine how an agent moves information around and uses tools; that's engineering. The semantic layer defines what "good" looks like for a user in a particular situation, which has always been design work. Before components and tokens took center stage in the 2010s, we called much of it information architecture.

AI is bringing IA back into the conversation, but now we're mapping experiences for machines as well as people. The questions remain much the same: What is the user trying to do? What state are they in? What should the system show them, and what should it hold back? Anthropic's SKILL.md format, adopted by OpenAI, Google, and dozens of tool vendors within three months, reflects the same idea at a much larger scale: a portable, machine-readable guide to doing something well. That's a design artifact, if anything is.

The work moves upstream, and that is the good news

I'm less certain about what happens next, but as building gets cheaper, I think more durable design work will move earlier in the process: framing the problem, doing discovery, deciding which pattern fits, and documenting that decision in a way a machine can use.

Some people on my team may end up writing pattern context full time, which wouldn't be a promotion so much as a shift in the work. Instead of reviewing screens at the end of a sprint, they might help define the machine's idea of "good" at the start of a quarter; it's still design, but the output is different and the work can have more reach.

I'm not the only one making this bet. John Maeda described this shift as the most profound in over a decade in his 2026 Design in Tech Report, while Ethan Mollick has urged readers to delegate implementation and focus strategic effort on problems agents can't yet commoditize. Figma's releases this year point in a similar direction, Gartner named context engineering the breakout AI capability of the year, and Workday's engineering blog is publishing playbooks for it under the banner of AX. None of this proves the case, but it does suggest that people across the field are looking at the same shift from different angles.

The idea that design work will move upstream is still early: on my team, it's a week of momentum and a working thesis, while across the field more people are talking about it than putting it into practice. If I'm wrong about how quickly the human work moves upstream, the practical case for the artifact still stands, because someone has to explain what "good" looks like to the machine, and that work exists today.

What becomes possible

This work matters because of the person on the other side of every agent-generated flow: someone opening a product for the first time, recovering from an error in the middle of an important task, working through a patient decision, or trying to buy something without being steered toward what they don't want. For years, those people's experiences have depended on who happened to be in the room when decisions were made; sometimes that was a designer, and often it wasn't.

A pattern library can change that by making the semantic layer explicit, so an agent's work can carry a designer's judgment about what will serve the person using it, not because a designer reviewed every screen before it shipped, but because a designer helped write the rules the machine used. One thoughtful pattern could shape thousands of flows the design team will never see.

The library also gives designers something concrete to point to and say, "This is why the AI made a good choice today," making the connection between design decisions and product outcomes more visible. Designers who write these context layers well could shape how their products feel for years to come, not by protecting a role, but by doing the work that matters as the field changes.

The most valuable artifact a designer writes this year may not be a screen; it may be the instruction manual.