My mindset right now is transformation vs adoption.

Most teams talk about adopting AI — slotting it into the existing workflow, keeping the workflow intact. I'm interested in the other direction: letting AI change what the workflow is for. When the tool stops being a way to render the same artifact faster, and starts being a way to do a different kind of thinking, the job itself reshapes.

That's the frame I'm working from. Everything else on this page is a consequence of it.

The double-duty problem

In Figma, every prototype I built was carrying two stories at once. There was the tool story — the thing engineering was going to build, the components and the states and the edges. And there was the artifact story — the customer experience the tool was supposed to create. Both stories had to live in the same fixed sequential flow. Both had to resonate across a wide population of customers who didn't share a context. One designer, two narratives, one shot.

The cognitive load of association

The trick I was asking customers to do, every time, was to associate my fixed story with the specific gap they had on their service team. That association was the work. It was invisible work — they did it in their heads — but it was the part that determined whether the demo landed. If they couldn't map my story to their situation, the value never showed up. We were dressing up Figma frames and hoping the bridge would form.

The AI-native flip

A prototype built on real infrastructure doesn't need to be sequential. The customer can bring their own case. The thing in front of them responds to their service team, their edge cases, their CRUD-and-empty-and-error states. The value stops being story-fitting and starts being service-knowledge specific. That's the part that feels like magic, but it isn't magic — it's the removal of the association load.

The reallocation

Here's the part that actually matters for the design discipline. When the tool doesn't absorb your time anymore, the only thing left is thinking about the customer. Research, service blueprints, customer journeys — these have been treated as nice-to-haves for years because most of the calendar was burning on getting a design reviewed and approved in Figma. They aren't nice-to-haves. They're the must-haves. They're what's left when the manufacturing of artifacts stops being the day.

It may start as uncomfortable until you understand the rhythm or you create one, then the rhythm creates patterns for others to follow. You socialize to bring others to that plateau, then move into the unknown and start all over until it becomes comfortable.

The pattern

Macy's. Albertsons. AWS. The arc looks like job hops, but underneath it's the same loop, repeated. Arrive somewhere new. Learn the landscape. Find the gaps the people who'd been there had stopped seeing. Build the mechanism that closes the gap. Push past the established norms when they're in the way. Share the mechanism so other people can run it without me. Then look for the next stretch — growth doesn't fall in your lap, and the frontier is where I want to be.

The reason it works is the rhythm. Discomfort is the start state — it has to be — and the work is to find or invent the cadence that makes the unfamiliar legible. Once that cadence exists, other people can follow it. Once they're following it, the plateau forms. Once the plateau forms, it's time to leave it.

Why this matters now

At AWS right now I have a carved-out role with autonomy: room to question internal guidelines, to stay on the bleeding edge, to share theories about what AI-native actually means. I'm not looking to sit back and cruise yet. I want to stay relevant — and the frontier is where that happens.