A note on AI, how we work, and what UX is actually responsible for now.

Let’s be honest about where we are.

AI is already in the building. Engineers are using it to write code. PMs are using it to draft briefs and summarise research. PMMs are using it to generate copy and positioning. Whether we planned for it or not, AI has quietly become a team member in every function — and like any team member without a proper onboarding, it’s working with whatever context it can find.

That’s the problem. And increasingly, it’s our problem to solve.

What AI actually is (and isn’t)

AI is a very fast, very capable processor of information. It can gather signals, synthesise data, generate structure, and produce output at a speed no individual function can match. That part is real and it’s not going away.

What it isn’t — and this matters — is a decision-maker. It doesn’t know your product the way your team does. It doesn’t carry the three months of user research that shaped the last major redesign. It doesn’t know why that edge case in the permission schema matters, or what your enterprise users actually mean when they say “it’s too complicated.” It produces output shaped by whatever context it’s given. If that context is thin, the output is generic. If it’s wrong, the output is confidently wrong.

This is the gap that sits in the middle of every team right now. And it’s the gap that UX is uniquely positioned to close.

What this means for us, day to day

There’s a version of UX that lives only upstream: research, wireframes, design systems, handoff specs. That version is real — and it’s still part of the job.

But UX also lives downstream. We’re the function that watches what happens after the product ships. We analyse usage data to understand which features get adopted and which get quietly abandoned. We read support tickets not as customer service noise but as a signal layer — patterns in what breaks, what confuses, what users ask for repeatedly that the product doesn’t currently offer. We track behavioural data alongside qualitative insight and synthesise both into something the rest of the team can act on.

That combination — upstream intent and downstream reality — is what makes UX’s view of the product uniquely complete. And it’s exactly what AI needs to do useful work.

Increasingly, how we package and share what we know is as important as what we know. Because our research, our design rationale, our usage analytics, our support ticket patterns, our documented edge cases — all of it is now also source material for every AI tool in every function around us.

When an engineer’s coding assistant generates a component, is it working with your design token documentation or guessing? When a PM’s AI drafts a brief, is it referencing your latest research synthesis — or the support ticket pattern that contradicts the assumption in that research? When a PMM generates product copy, does the AI know what your users actually call the thing, or what your analytics show they’re trying to do with it?

These aren’t hypothetical questions. They’re happening in every sprint, every document, every pull request.

UX Guardians and Guardrails

This is where the shape of the role starts to shift.

The UX team is becoming UX Guardians: not just makers of design, but custodians of the product knowledge that the whole team’s AI tools depend on. The craft doesn’t go away — the responsibility gets wider.

And the mechanism for doing that is what I’m calling Guardrails.

Guardrails are the specific instructions, context, and reference material we build into the AI tools each function uses — so that when those tools generate, they generate within the boundaries of what we actually know about our users and our product. They’re not restrictions. They’re the difference between an AI that produces generic output and one that produces output that’s actually calibrated to your product.

In practice, this means working with each function to embed the right product knowledge into their tools:

• With engineering: design tokens, component intent, documented edge cases, design system rationale — so AI-assisted development generates within the system, not around it

• With PMs: research findings, user mental models, validated pain points, usage patterns, and the support ticket themes that reveal where the product is failing quietly — so AI-drafted briefs are grounded in evidence, not assumption

• With PMMs: user language, positioning constraints, the words your users actually use in support requests and research sessions — so AI-generated copy doesn’t introduce terminology that’s never been tested against real user behaviour

The Guardrails aren’t built only from what we intended the product to do. They’re built from what we can observe the product doing — and the gap between those two things is often where the most important context lives.

The UX team doesn’t control every tool. But we control the quality of the context those tools work from. That’s the new leverage point.

What this changes about how the team works together

A few things shift when you work this way.

Trust becomes the foundation, not the nice-to-have. When every function is partly dependent on the quality of every other function’s AI context, the handoffs between us matter more than they ever did. A research synthesis that sits in a folder no one can find doesn’t protect anything. A design rationale document that only exists in someone’s head can’t be a Guardrail. The work has to be shared, maintained, and actually usable by the tools around it — which means UX and the wider team need to trust each other enough to work that openly.

Quality of inputs becomes the new quality metric. We’ve always cared about the quality of our outputs. Now we also have to care about whether the right outputs are in the right place at the right time — documented, structured, and accessible enough that an AI tool can actually use them.

The UX team’s scope expands without the headcount to match. This is the honest version of “AI makes us more productive” — it does, but it also raises the bar for what good looks like. We can do more. We’re also being asked to cover more ground. That’s worth naming, not glossing over.

Where this is going

I don’t think this transformation is finished. We’re in the early stages of working out what it means for each function to become a guardian of their own domain’s AI context — and what the new rhythms of collaboration look like when every tool in every team is drawing from shared knowledge.

What I’m confident about: the teams that figure out the trust and the Guardrails early will be operating at a different level than the ones still treating AI as a personal productivity tool sitting in a silo.

Over the coming weeks I’ll be sharing experiments from inside our team — specific tools, specific setups, what worked, what broke, and what we learned. This post is the frame. The sub-posts are where it gets specific.

More soon.

Questions or pushback? I’d love to hear it — feel free to reach out.