AI prototyping has shifted the ground under product and UX teams. It reshapes team structures, redefines individual roles, and sometimes collapses the product development process altogether.

That can feel daunting. Here's the good news: gaps still sit between ideation and launch, and researchers, designers, and founders still have to fill them.

I learned this firsthand on an automation platform project. AI-based prototyping became my thought partner. It also showed me exactly where my thinking ran out. I filled those gaps with object-oriented UX.

Here's how it happened. I had just wrapped a cross-functional MVP workshop, and we had a clear path forward. I decided to test AI-assisted prototyping to see if it could save us time on an initial proof of concept.

Then I hit a wall. Before I could design anything, I needed a consistent system model.

I've watched the same thing happen to my coworkers and friends who prototype with AI. They sprint to a polished screen, then stall on a basic question: what exactly are we building?

My team had chosen a simple, two-step automation for the first release. I used an AI prototyping tool to explore three versions: an MVP, an MVP+, and a future-state automation experience.

I expected to validate an idea. Instead, the prototype exposed every ambiguity we hadn't untangled.

Take notifications. Should they live at the step level, the automation level, the project or folder level, or globally? I knew conflicting notifications would overwhelm users. I couldn't say where they belonged, or why.

Then triggers, the events that start an automation. Do they count as steps? Or do they stand apart from the steps inside an automation?

Normally those questions surface much later, after a team has built on shaky ground. This time, engineering was busy paying down tech debt, so we had room to invest in a shared system model. I proposed an object-oriented UX sprint to build it.

OOUX defines the objects in a system before it touches the verbs.

In a typical process, I finish discovery and definition, then start with user flows. That centers the work on what the user does. OOUX flips the order. It starts with the things that make up the experience, maps how those things relate, and only then defines the actions users take on them.

That difference mattered. Our open questions were about the structure of the system, not just its screens or flows.

I ran a multi-week OOUX sprint with a fellow designer who specialized in our developer and integration platform. His contributions were invaluable. Do OOUX work in a small group. You'll thank yourself.

We skipped the eight-hour sprint days that many guides recommend. Instead, we worked in chunks of two hours or less.

If you're running OOUX alongside other work and have the time, I highly recommend this approach. We kept our other projects moving and returned to the model with fresh eyes. System modeling drains your brain, and a second brain makes it bearable.

Here's the process, step by step:
‍
- Identify nouns. We listed the nouns in our own system and in competitors' systems, since we were building something net new.
- Define the core objects. We decided how they relate to one another.
- Document the actions. We mapped what users can do with each object across the system.

A CTA inventory spreadsheet turned out to be a big win. It forced us to think about permissions and roles alongside the core actions. And we hadn't drawn a single screen yet.

AI shone at generative work. It surfaced nouns, verbs, and things we might have missed.

It struggled with nuanced relationship decisions, and it sometimes contradicted itself. Our definitions, domain knowledge, and judgment had to drive the model. AI didn't save us time when we made the key product decisions.

With a concrete model in hand, we drew object wireframes for each core part of the automation experience. I figured they'd help the AI tool understand how and where the objects should live, far better than a bare list of definitions.I fed every OOUX output into my prompts, along with a sitemap and parity requirements so we wouldn't lose any existing automation functionality. The goal: a tangible version of our vision that we could share with stakeholders.

The vision prototype took on a life of its own. Leadership shared it with each other, unprompted. It turned a complex system model into something tangible, real, and consistent. Stakeholders could build nearly any kind of automation, and they could explore a dashboard, a list view, and full settings.

Months later, another team came to us with an urgent customer need: automation embedded inside their existing platform. We used the shared OOUX model to keep their solution cohesive with ours.

What began as a way to clarify one workflow builder became a shared way to reason about automation across experiences.

Watch for these red flags. Any one of them says the system model should come first:

- The same concept could live at several different levels of the experience.
- Different teams use different words for the same thing.
- You can draw the user flow, but you can't explain how the core pieces relate.
- Every new use case forces you to rethink the basic structure.

Most teams use rapid prototyping to bring an idea to life once they already know what to build. But when prototypes turn fast and disposable, they can move much earlier in the design process.

In my case, the prototype did more than represent my thinking faster. It became a thinking partner that showed me where my thinking fell short. OOUX then gave us a way to close those gaps before they hardened into an interface.

AI didn't eliminate the need for foundational design work. It helped us discover that need sooner. For complex platform work, that beats reaching a first proof of concept faster.

If your team ships prototypes faster than it understands its own system, [Mayur Maheshwari / mayur@studioaccorde.com]. Let's build the model before you build the screens.