Defining the problem
AI's impact on this stage
Changed it completely.
Learning a new domain used to mean months of waiting on engineers. It took weeks of reading.
Most of what I hear about AI in design is about generating screens. In enterprise software that isn't where the constraint sits. The constraint is that you can't design for a domain you don't understand, and understanding one has always meant months of borrowed time from engineers. So that's what I pointed AI at first.
I worked through the product specification with AI until I understood not just what the capabilities were, but how work moves in this field: who does what, who hands off to whom, what happens outside our product entirely. The features I could have read off the spec. The workflow around them is what tells you what the experience needs to be.
It also changed how I arrived at proposals. I could put a hypothesis up, have it pressure-tested, refine it, and do that several times before it reached a person. By the time I brought something to a PM or a domain expert, it was worth their time.
Execution
AI's impact on this stage
Made it cheap.
A working prototype used to cost engineering time nobody has at the design stage. I built one myself.
Execution here meant two things: deciding the shape of the thing, and building something that let people see it.
In this domain, the new capabilities and the assets they concern normally live in separate applications, owned by different teams. To trace an issue to its source, users move between systems.
Embedding was the better answer here. Because the new area lived alongside the assets it concerns, someone could investigate a problem and act on it without leaving the product.
The organizing principle was a loop. Three personas work with this information from different vantage points, and each view risks becoming a dead end. So I designed the flows so information connects: what surfaces in one persona's view ties into what the others need.
Then I built the prototype myself, in functional HTML where users could add and edit, with connected sample data underneath, while engineering was still working through the data layer. A Figma prototype tests pictures; every screen is its own drawing. Here, what a user created in one place showed up everywhere it should.
Judgment
AI's impact on this stage
Sped up exploring, not deciding.
AI made exploring options cheap. Deciding which option was right for this product was still my job.
Embedding is easy to decide and hard to specify. Each of the five capabilities had to find its place among features that already existed: what it sits beside, what it inherits, what it interrupts.
What AI did: generate candidates, fast and repeatedly. Describe a problem, get a structure back, push on it, get a revised one, several rounds in an afternoon. Exploring an option used to mean committing hours to it.
What I did: decide which candidate was right for this product. Here's the clearest case.
Because the market keeps these two systems apart, the established pattern is to detect a problem, notify someone, and let them go elsewhere to act on it. AI's proposals kept landing there, not because they were poor designs, but because that's what exists, and that's what it had read.
We were embedding, so the asset was already present. The design could go past notifying: someone could act on the problem where they found it. That option isn't in any reference material, because these two things haven't been in the same place before.
So every round went the same way. AI returned a sound design for a world where the systems are apart; I brought back what our product actually makes possible, and we went again.
AI is fluent in what already exists. A new product area is, by definition, the part that doesn't.
Validation
AI's impact on this stage
Built the test, not the verdict.
AI helped build what we tested with. Only people could tell us whether it was right.
The prototype is why we could put this in front of domain experts months before the build: it existed, and it behaved like the real thing. Without it, the session would have been a walkthrough of static screens, and we'd have collected opinions about screens.
Working in something real, the experts stopped describing requirements and started reacting to a proposal. Two things surfaced that no amount of reading the specification would have produced, because neither is in it.
Prioritization is the job. Findings far exceed what anyone can act on, and most are noise. It isn't a capability sitting on top of the work; it is the work.
The overview was solving for the wrong scope. I'd designed it for someone responsible for the whole system, which is what a specification describes. But much of the daily work happens inside an assigned scope, and for those people a complete view is the wrong view. They need a filtered one. A spec tells you what a system does. It doesn't tell you how responsibility gets divided among the people using it.
Both went into the next iteration.
What I'd do differently: my sample data was coherent but clean, and the real world here is anything but. With realistic volume in the prototype, the prioritization problem would have surfaced before I sat down with anyone.
AI got me fluent. Knowing what was wrong was still my job.