The moment something felt wrong wasn’t when the product failed.
It was when it felt too much like filling out a form.
This post is about a subtle but critical UX problem I ran into while building uipad—and how it forced me to rethink what “progress” actually means in an AI product.
1) The uneasy feeling: am I doing work, or feeding the system?
Early versions of uipad followed a very reasonable pattern:
- You provide some context
- The AI asks follow-up questions
- You refine, clarify, confirm
- Then you move on
On paper, everything worked.
But after using it myself a few times, a quiet discomfort showed up:
Am I actually accomplishing something—or just supplying data?
Nothing was broken.
Nothing was confusing.
And yet, it felt like I was stuck in a loop of “just one more input.”
2) The trap many AI products fall into: inputs become the experience
This isn’t unique to uipad.
A lot of AI tools accidentally inherit the mental model of forms:
- Progress equals answering questions
- Completion equals finishing inputs
- The interface rewards filling things out
In traditional software, that’s tolerable.
In AI products, it becomes dangerous—because the AI can always ask more.
3) The real issue wasn’t too many questions—it was invisible completion
The key realization was simple:
If a step ends without a visible outcome,
it never truly ends in the user’s mind.
Without a clear “you’ve finished X,” the experience feels endless.
Users don’t feel progress.
They feel extraction.
4) The shift in uipad: designing completion around outcomes
I stopped asking:
“Have we collected enough information?”
And started asking:
“What has the user completed at this moment?”
That question reshaped the product.
✅ Change #1: completion screens show results first, not buttons
In uipad, a completed step no longer drops you into a “continue” button.
Instead, it opens with a clear outcome:
✅ Icebreaker · Judgment Set
3 prompts generated · Estimated time: 3–5 minutes
This is a completion anchor.
It tells the user:
you finished something real.
✅ Change #2: replacing “results” with a “deliverables pack”
Instead of dumping generated text, I framed the output as a package:
Icebreaker Deliverables
Which includes:
- 🎤 Host script (readable, spoken language)
- 🖥 On-screen display preview (for the room)
- 👥 Participant-facing description (one sentence)
This reframing matters.
It shifts the mental model from:
“The AI generated text”
to:
“I now have materials I can use.”
✅ Change #3: previews are part of progress, not decoration
In many products, previews are optional.
In uipad, previews are the experience.
They help users imagine:
- Standing in the room
- Holding the cue cards
- Running the moment
That imagination is what replaces the urge to keep tweaking inputs.
5) From input-driven to outcome-driven AI UX
The principle I now design by is simple:
AI UX should be judged by what users take away,
not by what they type in.
Inputs are necessary.
But outcomes are what create closure.
If users can’t say:
“I just finished X,”
the product will always feel unfinished.
6) A quick self-check for AI product builders
If you’re building an AI tool, try asking:
- After each step, can users name what they completed?
- If all input fields disappeared, would the product still make sense?
- Can the output be directly used, printed, shared, or acted on?
If not, your product might be drifting toward being a very advanced form.
Closing
One internal rule I now keep close while building uipad:
If a feature can’t be “used in the real world,”
it’s probably serving the system more than the user.
This post isn’t a victory lap.
It’s a reminder—one I expect to need again.
And maybe, if you’re building with AI too, it’ll save you a similar detour.