Agents that Design Agents (Part 2): Design the Experience

A good idea is only the starting point. A design agent helped me turn one into a blueprint for a working solution in about ten minutes.

For several years I worked closely with a mentor who would bring us back to the same questions whenever we talked through a solution design.

What problems are we solving, and for whom? What would a suitable solution look like for them? Beyond business outcomes, what would change in their experience? Six months from now, if we got it right, what would people be saying, feeling, or noticing that told us things were better?

He's the person who first encouraged me toward design and experience work, and much of how we work at Kinetiv traces back to what I learned from him. Progress over perfection. Think big, start small, move fast.

Those questions are also built into the idea-brief agent from the first post in this series. It gives me and my AI collaborator a shared target: the problem, the people, and what done looks like.

But a good brief still doesn't say what to build. Someone has to work out how people will interact with the solution, what they'll see and do, and what has to happen behind the scenes to make that experience work.

That's the design step, and the second of three agents I use before I build.

Connecting the experience to the build

The design agent turns the idea brief into a UX blueprint using a service-blueprint approach. Across the top are the steps a person moves through, how they interact with the solution, and what success looks like at each point. Underneath are the processes, systems, and data needed to make those moments work.

That connection is the part I care about most. It keeps the build tied to the experience we're trying to create, instead of letting the technology define it.

The agent drafts the blueprint from the brief, asks only what it can't work out on its own, and waits for my approval before turning it into user stories.

For the bank prospect from the first post, that meant designing around the comms team reviewing incoming requests. A request arrives. They see it in their queue. They review what the agent prepared, either a draft brief or a reply asking for missing information, and decide what happens next.

The design agent's blueprint, simplified: what the comms team experiences at each step, and what has to exist behind it.

About ten minutes after the idea brief was done, we had that experience mapped, along with the pieces needed behind it.

Get something real in front of people

The point of the blueprint is to get to something people can use, as quickly as possible.

People respond differently to a working solution than to a concept. A description can sound right in a meeting. Put even a rough prototype in someone's hands, and what's right, what's missing, and what was misunderstood show up much faster.

For the bank, the first conversation took about an hour. Within a day there was a working prototype to react to: small, but running end to end, taking real requests in and producing real outputs.

That's where "start small, move fast" matters to me. The goal is the smallest version of the whole experience that someone can use from start to finish and react to.

Enough structure to move fast

This is also where I feel the tension I wrote about in Keep, Compress, or Drop. I've spent much of my career around design methods that can produce a lot of documentation before anyone gets to touch the thing being designed.

Some of that rigor exists for good reasons. I don't want to replace it with chaos. But I also don't want the documentation to become the work.

For me, the useful minimum is fairly simple: know whose experience we're designing, how they'll interact with the solution, and what has to exist behind it to make that work.

AI compresses much of the work required to get there. It doesn't decide whose experience matters or what the first version should include. But I can make those decisions with a concrete blueprint in front of me, instead of spending days producing one.

My mentor's questions were never meant to end with answers on a page. Design is where those answers start becoming something a person can use.

The next question is whether the technology can make that experience real and, with AI capabilities changing so quickly, what the right way to build it is today. That's the architecture step, and it's where the next post picks up.