Most AI design workflows start with a prompt. I found that asking one model to think, remember, design, and build at the same time produces generic work — and on a regulated platform, generic is a liability.

I didn’t ask one AI to do everything. I gave each tool a single job, drew hard lines between them, and kept judgment at the center where it belongs. Over the past several months I led the end-to-end design of a large commercial platform.

I can’t tell you what it was. I can tell you how it got built. The move that mattered: I stopped treating AI as a faster design tool and started treating each tool as a specialist collaborator with one clear responsibility — then refused to let any of them freelance outside it. This was never about automating myself out of the work. It was about getting through more good decisions per week without dropping the bar.

Every call still ran through me. The tools just closed the gap between making a decision and seeing it come to life.

The “before” state isn’t a tool — it’s a habit. Open one AI, ask it to think, remember, design, and build in the same thread, and watch it default to the generic answer the moment the context runs thin.

On a platform with eight complexity domains, that default is the risk. Old: one chat window, one model, one context that quietly drifts. New: five specialized layers, each with a single responsibility and a clean handoff to the next — strategy, memory, system, prototype, high-fidelity design. Real-time systems. Compliance. Financial logic. Authentication. Identity. API integrations. Media. Permissions.

Here’s the thing about AI and context: when it doesn’t have enough, it reaches for generic. On a platform like this, generic isn’t good enough. It’s a liability.

Every tool should do one thing exceptionally well. I never asked a single platform to think, remember, design, and build at the same time. Each layer of the workflow had its own specialist, and I policed the borders between them.

Strategic thinking — Claude. Claude was my product strategist. Before a single screen existed, we talked through feature definition, information architecture, user journeys, interaction models, and the trade-offs between all of them. This stage produced zero UI, and that was the point. I was building understanding, not pixels.

Persistent memory — Notion. Notion held the project’s long-term memory. The part that surprised me: I almost never opened the backlog myself. Claude pulled from it and reasoned over it in conversation, so the backlog stopped feeling like software I had to drive and started feeling like context that was simply there whenever we worked.

System definition — Figma. Once the direction was set, Figma became the source of truth for the visual language. I kept exploration out of Figma on purpose. Figma’s job was to pin the system down with precision.

Functional prototyping — Claude. Claude translated the locked design system into working code. “Mockups” is the wrong word for what came out of this. Each one was closer to an executable spec — proof that the logic held up, not just that the layout looked right.

High-fidelity design and handoff — Claude Design. Claude Design came in last, once the hard calls were behind us: strategy set, interaction model agreed, design system locked. Its job wasn’t to invent anything. Because the thinking was already done and the system was the input, this stage moved fast and stayed on-system by default. Nothing drifted. What came out was the artifact stakeholders actually reviewed — close enough to the real thing that people reacted to the product instead of imagining it — and a far richer reference for handoff than static screens ever could be. Engineering still owns production. This just made sure they started from something unambiguous.

The workflow keeps strategic thinking, memory, system definition, functional prototyping, and high-fidelity design in separate, specialized layers. That’s what lets AI accelerate execution without the product paying for it in quality or design intent.

The tools will churn. Half this stack could look different in a year. The division of labor underneath them is the part I expect to keep.

This is the question most teams skip, and it’s the one that decides whether any of this was worth it. The wrong move is to point all the saved time at shipping sooner. Speed on its own just gets you to the same place earlier — mistakes and all. When a prototype costs an afternoon instead of a sprint, “let’s just try it and see” becomes a reasonable thing to say out loud, and you learn things you’d otherwise have shipped right past.

Where I’d spend the surplus, in order:

• Test what there was never room to test. The assumptions that got cut for time on every previous project are now an afternoon each.
• Chase the small, messy problems. The customer problems that never made the roadmap because they couldn’t justify the old build cost — now they can.
• Ship sooner — where the case is clear. Only where the risk is already understood. The real return on cheaper execution isn’t more output. It’s better questions.
• Quality has one owner. None of it changes who’s accountable. I am. The tools don’t carry the risk, they don’t answer for a confusing flow or a compliance gap, and they can’t be held accountable to a user. Faster generation raises the bar on judgment — it doesn’t retire the person applying it.