AI as the Consumer: Optimizing UX Deliverables for AI Consumption

Recap of a talk given at Agentic UX Summit, September 2026

Think about the last research deliverable you made. A persona, a journey map, a readout deck. Who was it for?

For most of us, the answer has always been obvious. A person. A stakeholder, a product manager, a room full of engineers who needed to understand the user before they built something.

That audience hasn't gone anywhere, but it has company now. More and more often, the first thing to read our work is an AI agent, summarizing it, searching it, or pulling from it to answer someone else's question. And most of what we make, it can barely read.

What's compelling to humans is unreadable to systems

Our deliverables are good at their original job. A slide deck follows a narrative arc. A journey map lets you trace an experience across a page. A persona builds empathy fast with a photo and a few quotes.

Hand those same artifacts to an AI and they fall apart. A deck has no schema, so a bullet could be a finding, a header, or a joke. A journey map's findings live in its layout, which is exactly what an AI can't parse. A persona that says a sales rep "hates re-entering data" is compelling to read, but that line isn't tagged or scored, and nothing can compare it to anything else we know.

The insight is there. The system just can't see it.

Separate the two jobs

Every deliverable is quietly doing two jobs. It has to be usable by people, and now it has to be parseable by machines. Trying to do both in one artifact is where things break.

So separate them, and work backwards. The structure layer holds the content in a form a machine can read. The presentation layer is what people see, and it's built from the structure. Start by picturing what the presentation needs to become, then design the structure that can feed it.

That asks something uncomfortable of designers. As I put it in the talk: your job is not making designs. Your job is making the source of truth.

In practice, that means starting with different questions:

• What data sources do we have to work with?

• How do we turn unstructured data into something usable?

• What assets do we need to produce from it?

• How do we know when an asset needs an update?

• How do we make sense of everything we have?

I called this thinking like a data sherpa.

It's about efficiency, but it's also about respecting our participants. People gave us their time and told us about their work, and their insights deserve better than a slide nobody opens again.

Five principles for AI-readable deliverables to power your knowledge automation

Structured over visual. A record has to exist in structured form, like a spreadsheet row or a JSON file, before an AI can act on it. A beautiful Figma board is a dead end for automation until someone translates it. My test: if you can't point to a field, a row, or a JSON key that holds this content, it doesn't exist yet, no matter how good it looks.

Controlled vocabulary. "Onboarding friction," "new user confusion," "activation issue." Is that one problem or three? A person can usually tell from context. An AI will guess. Fixed, documented value sets for things like department, journey stage, and persona let it extract consistently.

Single source of truth. Every downstream view stores a reference, usually an ID, and looks up the real content live. The pain points on a persona page point back to the master list instead of copying it, so there are never two versions to reconcile.

Separate meaning from identity. We've all seen Final_journeymap, Final_Final_Journeymap, and Real_Final_Journeymap. The same problem shows up in IDs. When a category or status is baked into an ID, changing the category breaks every reference to it. I learned this one the hard way. Keep classification in its own field so it can change without taking everything else down with it.

Evidence as a first-class field. An AI's output is only trustworthy if it can point back to its source. In our repository, every pain point carries its severity scores, the number of independent sources behind it, and a link to the study it came from. Trust comes with verification.

Putting it to work

These principles came out of a pipeline I built and now run to keep our research corpus current. A researcher uploads a new study. Claude extracts the findings, scores each one, and compares it against our five core research assets to see whether it conflicts with, reinforces, adds to, or nuances what we already know. Every score needs a supporting quote. No quote, no score. Then the asset owner sees a before-and-after with the source attached and decides whether it goes live.

One upload can update several assets at once, which is only possible because the assets were structured first.

The full walkthrough is in the case study.

Where to start

Structure is the deliverable now. The pretty version is a rendering of it.

Retrofitting costs 10x what building it right costs.

Not everything should be machine-optimized. Protect the parts that shouldn't be.

So pick one deliverable you own. Could an AI read it without an explanation or a companion summary?

If not, that's your starting point.