Topics
September 3, 2026
.png)
September 3, 2026
Rapid prototyping with AI has quickly shifted the ground under product and UX teams, transforming team structures, redefining individuals’ work, and sometimes collapsing the typical product development process.
And while such a big change can feel daunting, the good news is that there are still plenty of gaps UX researchers, designers, and product creators need to fill between the stages of ideation through launch.
During a recent project with Paylocity, our team discovered how AI-based prototyping actually helped us as a thought partner—but we still had gaps to fill, and did so with object-oriented UX.
I’ve written about this project quite a bit already: defining the future of an automation platform. I had just finished facilitating our cross-functional MVP workshop, and we had a clear MVP path forward. I decided to experiment with AI-assisted prototyping to see if it could save us time in building an initial proof of concept.
But as I started prototyping, I quickly realized we needed a consistent system model to design from first.
Our cross-functional team had chosen to focus on a simple, two-step automation for our first release. I started using Figma Make to rapidly explore what an MVP, an MVP+, and a future automation experience could look like. Instead of validating an idea, the prototype revealed a lot of the ambiguity we hadn’t untangled just yet.
For example, when adding notifications, I realized we needed to decide whether they should live at the step level, the automation level, a project or folder level, or at a global level. I knew we didn’t want to overwhelm users with conflicting notifications, but I wasn’t sure where they should go—or why.
Another example was a trigger: something that starts an automation. Should triggers be considered steps? Or are they distinct from the steps within an automation?
Normally, those open questions would have surfaced much later. With engineering working on tech debt first, we had time to invest in creating a shared system model. I proposed running an object-oriented UX sprint to do just that.
If you’re not familiar with this methodology, OOUX starts by defining the objects in a system before getting to the verbs.
In a typical design process, I might start with user flows after discovery and definition are done, centering the work around what the user is doing. OOUX, on the other hand, begins with the things that make up the experience, how those things relate to each other, and only then the actions users can take with them.
That distinction mattered here because our unanswered questions were about the structure of the system, not just its screens or flows.
I used OOUX to create that shared system understanding in a multi-week sprint, alongside a designer I was mentoring, who specialized in our developer and integration platform. His contributions were invaluable to the project, and I recommend doing any kind of OOUX work in a small group.
Instead of cramming everything into eight-hour sprint days like we saw recommended online, we broke the sprint into chunks of no more than two hours at a time.
I would highly recommend this approach if you’re doing OOUX alongside other work and have the luxury of time. It enabled us to continue working on our other projects and come back to the model with fresh eyes. System modeling is really mentally taxing, and having a second brain was invaluable.
Once we got started, this was our step-by-step process:
Filling out a CTA inventory spreadsheet was also extremely helpful because it pushed us to think about permissions and roles alongside those core actions. And we hadn’t created a single screen just yet!
AI was useful for generative work like identifying nouns, verbs, and things we might have missed. It struggled with nuanced relationship decisions and sometimes contradicted itself, so our definitions, domain knowledge, and judgment still had to drive the model. It didn’t save us time further along the sprint when making key product decisions.
With a concrete system model in place, we started creating object wireframes for each core part of the automation experience. I figured this would help Figma Make understand how and where the objects should live, beyond simply entering a list of definitions.
In addition to the wireframes, I provided every OOUX output in my Figma Make prompts to create a tangible representation of our vision for automation that we could share with stakeholders. I also included a sitemap and parity requirements to ensure we wouldn’t lose any of our current automation functionality.
The resulting vision prototype became an artifact leadership organically shared with each other. It had transformed a complex system model into something tangible, real, and consistent. Stakeholders could go into it and create nearly any kind of automation, in addition to exploring a dashboard, list, and comprehensive settings.
Months later, another team came to us with an urgent customer need for automation embedded inside its existing platform. We used the shared OOUX model to help ensure that its solution would remain cohesive with ours.
What started as a way to clarify one workflow builder became a shared way to reason about automation across experiences.
A few signs that an underlying system model may need to come first:
I often see rapid prototyping used to bring an idea to life quickly, usually once a team already knows what it wants to build. But when prototypes become fast and disposable, they can move much earlier in the design process.
In this case, the prototype wasn’t simply a faster way to represent our thinking. It became a thinking partner—one that showed us where our thinking was incomplete. OOUX then gave us a way to resolve those gaps before they became embedded in an interface.
AI didn’t eliminate the need for foundational design work. It helped us discover the need for it sooner. And for complex platform work, that may be far more valuable than getting to the first proof of concept faster.
