We were designing an Agent-driven creation flow — user describes an idea, Agent builds a working application from it. The most natural design: Agent asks a series of questions, gets clear on the requirements, then generates the result.

That sounds user-centered. We're listening to what users want, not guessing.

But when we actually built it and put it in front of users, here's what happened: after three or four questions, they'd stop and say — "Just decide the rest for me."

We assumed it was a volume problem. Reduce five questions to three and the experience should improve. It didn't. The pattern persisted. That told us the issue wasn't the number of questions — it was the act of answering them at all.

01

Answering Questions Is Actually High Effort

When we went back and interviewed users, we found something we hadn't expected: by designing a "ask first, generate later" flow, we had transferred the learning work onto users. We were asking them to understand the internal mechanics of how the platform creates things — and then answer questions about those mechanics.

Even technical users don't think that way. Their mental model starts from the outcome: I want to build a bookkeeping app. Not: does it need to connect to a bank API? Should data live in a database or locally? How should user authentication work?

Users can answer those questions. Some of them will even go look up "what's an API." But the act of answering is itself a burden — they're doing work that shouldn't be theirs to do, just to keep the conversation moving.

02

Flipping the Decision Point

Once I saw it that way, the real question wasn't "what should we ask, and how many questions." It was: who should be doing the work of turning a vague idea into a set of specific decisions?

Two positions
If the answer is "the user" Asking first makes sense — assuming the user actually has the clarity and willingness to do that work. Like a client who knows exactly what they want and is comfortable articulating it precisely.
If the answer is "the platform" The flow needs to go the other direction. Agent makes some reasonable assumptions, generates something concrete and visible — even if some of the details are just placeholders — and now the user isn't facing "how do I build what I want" but "is this what I want?"

These two questions look similar on the surface — both seem to be asking for user input. But they require completely different things from users. "How do I build it" is a translation from outcome to mechanism. That's the work of a creator. "Is this what I want" only asks users to compare a result against their own sense of what's right. That's the work of a reviewer. And evaluation is something almost everyone can do without any training — we do it every day, pointing at things and saying "yes, that" or "no, not that."

03

An Assumption Is an Invitation

We had some internal debate about this. Would users feel like the system was making decisions on their behalf without permission?

My read: it's an invitation. It gives users something concrete to point at, instead of asking them to describe something from nothing.

Making an assumption isn't about replacing the user's judgment. It's about lowering the barrier for them to express it. A user who had to describe a vision from scratch now faces a version that already exists. They just have to say "this part isn't right" — and identifying what's wrong is much easier than describing what it should be. A rough placeholder actually creates a clearer starting point for the user to work from.

One thing worth stating clearly: this approach — assume first, let users adjust — works for creative, iterative contexts. Generating a first draft, a design sketch, something that can be changed and redone. It's fundamentally different from high-stakes, irreversible decisions, where the opposite principle applies: stop and ask rather than assume. These two principles belong to different categories of tasks. Applying the wrong one in the wrong context causes real problems.