Designing Swoop as a product system.
Swoop began with a customer need, not with an AI solution. The hard part was never generating slides — it was turning separate AI capabilities into one product that understands the job someone actually came to do.
Director of Product Design & Research — both strategist and hands-on IC on this one. Framed the problem, ran the two experiments, and designed the intent model and the agent architecture myself.
Two experiments, in the order the evidence demanded — both built as working, AI-integrated prototypes, not slides. The first tested generation; what it surfaced reframed the second around a research question: how do we know what someone actually needs. I shipped code to production alongside engineering throughout.
Not "create a Prezi". Understand the complexity of a user's content, context and goal — then create the right presentation for that situation. A broader job than the product was built to serve.
Swoop shipped publicly as Prezi's AI communication agent, built on the intent and context model described here.
Decks exported per active user nearly tripled in the two months after launch (0.76 → 2.52), as generation quality and onboarding matured.
The tension I found before the AI.
People needed to communicate. They did not always need a Prezi.
I identified a product tension: users came to communicate through presentations, but the Prezi format was not always the answer. Many wanted conventional linear slides, or needed to export a classic PPT or PDF to hand to someone else.
Stated as a job to be done, the product was serving a narrower one than people were hiring it for. The job was not create a Prezi. It was create the right presentation for this situation — where "right" is decided by the audience, the occasion and the file format the other side expects, none of which the product was asking about.
That framing did the real work later, because it is what kept the project from becoming "add AI to the editor". If the job is producing a finished, situation-appropriate presentation, then generation is one capability among several — and the interesting problems sit around it, not inside it.
When generative AI made autonomous slide creation possible, we began running early experiments on a strategic intuition: that the product could move from handing people creation tools to producing a finished presentation with them.
Two experiments, in the right order.
Generation was the obvious problem. Intent was the real one.
Experiment one — generation
I started with a project that specified in detail how generation should work: what a good deck looks like, what the system decides, what stays with the user. It answered the question we had asked.
Experiment two — intent
It also surfaced the problem underneath it, which is a research question before it is a design one: how do we know what the user actually needs?
Real product conversations showed the same job stated in very different ways. Some people arrived with a detailed brief already written. Others wrote a handful of words and expected the product to take it from there.
One clarification flow could not serve both. Asking a fully briefed user unnecessary setup questions is friction; asking a sparse-input user nothing leaves them with a generic deck. Defaulting to one flow for everyone would have served neither. The finding reframed clarification from a screen into a decision the system has to make, every time.
Ask only when the answer would change the result.
Three states, one rule.
This led to a guard-agent model. Purpose, audience and length are each classified as explicit, inferable, or genuinely unknown. The system asks only when the missing information would materially change the output — not whenever a field is empty.
- Explicit — stated by the user. Trusted immediately, never re-asked.
- Inferable — derivable from the uploaded material or the conversation. Used, but surfaced so it can be corrected.
- Genuinely unknown — and consequential. This is the only case that earns a question.
The rule is what makes it a product decision rather than a prompt: it defines when the system is allowed to spend the user's attention.
From capabilities to an experience system.
The map was not a prediction. It was a way to see dependencies.
From those learnings I designed a high-level vision of the end-to-end experience and mapped an architecture of collaborating agents — connecting intent and context to orchestration, specialist capabilities, quality controls and feedback.
This early system model was not the final production architecture. Its value was different: it gave product, design and engineering a shared language for arguing about how the experience should work and what had to happen behind it. It exposed which signals we could observe, what the system could safely infer, what required confirmation, and where context had to be shared across the experience.
The design material changed. I was no longer defining only screens and flows — I was defining decision logic, context boundaries, tool permissions, recovery behaviour and evaluation criteria.
Carrying context without unsafe assumptions.
Context has to follow the job, not the feature.
The cross-cutting problem in that architecture was connecting stages without forcing the user to understand the agents or models underneath. Context had to follow the job across the journey rather than being recreated by each feature — and it had to do that without the system quietly deciding things about someone.
So I separated context by what it is and how much it can be trusted:
- Who the user is — role, industry, organisation.
- What their creative identity is — brand, tone, visual direction.
- How they prefer to work — structure, density, recurring scenarios.
Each carries a different permission. Explicit information can be trusted immediately. Inferred preferences require confirmation. Repeated patterns can become persistent. And universal rules — accessibility, security, data integrity — cannot be overridden by any of them, no matter how strong the signal.
What this changed about the work.
I stopped designing only screens.
The design material changed. I was no longer defining screens and flows — I was defining decision logic, context boundaries, tool permissions, recovery behaviour and evaluation criteria.
None of that shows up in a mockup. What a user sees is an input and a finished deck. The product is the set of rules underneath: when the system acts on its own, when it stops to ask, and what it is never allowed to assume about someone.