AAR on UIPad Blog

How I Stopped My AI Product from Feeling Like a Form

Fri, 20 Mar 2026 17:30:00 +0800

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.

Why I Built uipad as Offline-First (and Refused to Build Live Polling)

Fri, 20 Mar 2026 11:20:00 +0800

The most valuable thing in an in-person event isn’t engagement data.
It’s presence.

When I started building uipad, the obvious route was to make it “interactive”: QR codes, live polls, charts on a big screen—something that demos beautifully.

Instead, I made a decision that looks almost stubborn from the outside:

uipad is offline-first.
It does not provide attendee-facing interactions.
It helps the organizer run the room—with scripts, printable cue cards, and display assets.

This post is why.

1) The demo-friendly path is tempting: QR codes, live polls, results on screen

If you’ve built products, you know the pull of features that show well:

People scan a QR code
Everyone votes
Results animate in real time
The room reacts
Your demo looks “smart”

There’s a reason tools like Slido and Mentimeter exist: they specialize in live polling, Q&A, word clouds—audience interaction made easy. Slido⁴ Mentimeter³

So yes—building “interactive event tech” is a proven lane.

But for uipad, it wasn’t the right job.

2) The real problem I wanted to solve wasn’t interaction—it was confidence

uipad isn’t built for professional MCs or agencies.

It’s built for people who get stuck in the messy middle:

“How do I open without it being awkward?”
“What do I say next?”
“How do I keep momentum?”
“What if the room goes quiet?”

Those problems don’t need dashboards.

They need:

A clear structure (opening → warm-up → peak → closing)
Words you can actually say out loud
Materials you can hold in your hand
A plan that survives real life

That’s why uipad shifted from “interactive platform” to:

offline-first AI event planning assistant
focused on planning + host support.

3) Offline-first isn’t nostalgia. It’s respecting what in-person does better

In-person events are expensive and inconvenient for a reason:
they create types of connection screens struggle to replicate.

Face-to-face settings carry nonverbal cues, spontaneous side conversations, and shared energy—things that help groups bond and collaborate.¹²⁵

So here’s the uncomfortable truth:

If my product makes everyone pick up their phones,
I’m trading away the best part of being in the same room.

Live polling can be great in certain contexts.
But it can also fracture attention—especially in social gatherings, reunions, and ceremonies where “being present” is the whole point.

4) What uipad does instead: planning + host support (not attendee interaction)

I drew a hard line:

No attendee accounts
No QR-code voting
No real-time charts
No “everyone look at your phone”

uipad does two things:

A) Plan the experience

Build a realistic flow
Generate context-aware icebreaker prompts
Provide safe alternates (no personal boundary issues)
Keep activities executable by voice, hands, and movement

B) Support the host

Host scripts (what to say, how to transition)
Printable cue cards (A6/A5, numbered 1/2/3…)
On-screen assets (photo timeline prompts, titles, sequencing)

It’s intentionally backstage.

uipad doesn’t replace the human in the room—
it makes it easier for that human to lead.

5) The tradeoff: less flashy demos, more real-world usefulness

This choice has a cost:

You can’t show an exciting “live results” animation
You don’t get engagement metrics
Your demo is less “wow”

But the upside is the point:

The organizer can actually use it
The plan survives bad Wi-Fi
The event doesn’t collapse into screen time
Attendees stay in the room, not in an app

I’d rather ship something people describe as:

“This helped me run the event.”

than:

“That demo looked cool.”

Closing: restraint can be a feature

When technology makes it easy to add more, the more professional move is often to add less.

For uipad, that means:

offline-first event planning
in-person icebreakers without phones
host scripts + printable cue cards + display assets

That’s the product.

And the moment I committed to it, uipad stopped being an “event platform idea” and started becoming a real tool.

References

Mentimeter — Icebreaker apps and tools: https://teambuilding.com/en/articles/icebreaker-apps-and-tools
Slido — https://www.slido.com/
Gable — In-person meetings: https://www.gable.to/blog/post/in-person-meetings
McCormick (Northwestern) — Study: why in-person conferences still matter: https://www.mccormick.northwestern.edu/news/articles/2025/01/study-reveals-why-in-person-conferences-still-matter-in-a-virtual-world/
IXDF — UI form design literature: https://ixdf.org/literature/article/ui-form-design

Why I Stopped Building a “More Powerful Tool” and Started Building a More Focused Product

Thu, 19 Mar 2026 15:10:00 +0800

The hardest part of building as an indie maker isn’t can I build it?
It’s I can build it… so why shouldn’t I?

This post is a decision log from the early days of uipad—an offline-first AI event planning assistant that helps organizers design a great in-person experience and walk into the room with a host script and printable cue cards in their pocket.

It’s not a tutorial. It’s the moment I realized that “more features” was quietly becoming “less product.”

1) My original plan: a tool that could plan everything

If you’ve ever built a product from scratch, you know the temptation:

Add one more feature so it feels “complete”
Support one more scenario so the market looks bigger
Copy the playbook of existing platforms so people “get it”

That was me at the start.

My mental model of uipad looked like a typical event SaaS:

Full multi-day agendas
Participant-facing interactions (polls, live Q&A, real-time results)
Dashboards, stats, “engagement”
The whole “platform” vibe

It sounded reasonable. It also sounded like a product I could pitch in one sentence.

And that’s exactly why it was dangerous.

2) The moment it started breaking: complexity grew faster than value

As soon as I tried to design the experience, something felt off:

Every new feature introduced a new state to manage
Every new scenario stretched the UX and made the flow harder to explain
The AI started “helping” in ways that weren’t consistent—because I wasn’t giving it a tight box
Worst of all: I struggled to describe what the product was without listing features

That’s the classic shape of feature creep: “just one more feature” snowballs into a bloated scope that dilutes the core value proposition. Product scope is literally your boundary—what you will build, and what you won’t—without it, you’re building in the dark. 1

I wasn’t failing at execution.
I was failing at definition.

3) The turning point: I wrote a Not‑To‑Do list before writing more code

I stopped asking:

“What else should I add?”

And asked a more useful question:

“If I keep going like this, where does this product die?”

Then I wrote a Not‑To‑Do list. Not as a manifesto—more like guardrails.

No participant-facing live interaction system
No QR-code polling
No real-time charts and dashboards
No full multi-day agenda builder (at least not now)
No features that pull people back into their phones during an in-person event

This wasn’t me “cutting features.”
It was me choosing what uipad would stand for.

And something surprising happened: the product instantly became easier to design.

4) The reframe: from feature-driven to boundary-driven

Once those “No’s” were explicit, uipad stopped being “an event management platform” and started becoming something sharper:

uipad is a planning pad for offline events.
It helps organizers design the flow, write what to say, and prepare materials they can actually use in the room.

That shift did three things:

It clarified the job-to-be-done
Not “manage an event.”
But “help me run this event without awkwardness and chaos.”
It tamed the AI
When your product is “everything,” AI outputs can go everywhere.
When your product is “this specific outcome,” AI gets predictable.
It made the UX simpler
Instead of building an endless editor, I could build guided blocks: opening → warm-up → peak → closing.

That’s the difference between shipping features and shipping a product.

5) What uipad became: an offline-first AI event planning assistant

This is the part that looks counterintuitive in a world full of “interactive” event tech:

uipad is intentionally offline-first.

It focuses on two things only:

A) Planning (designing the experience)

A structured flow that won’t fall apart in real life
Activity blocks that are realistic for in-person attention spans
Copy that feels like a human wrote it (and is safe)

B) Organizing (helping the host do the job)

Host scripts
Printable cue cards (A6/A5)
Large-screen “display assets” (like photo timeline prompts)
A participant-facing info page (not an interaction page)

That’s it.

No “everyone scan and vote.”
No dependency on Wi‑Fi.
No forcing participants into another screen.

In other words: uipad is the backstage operator, not the onstage platform.

6) MVP isn’t “minimum features”—it’s “maximum clarity”

A lot of people talk about MVP as “the smallest set of features.”

But that framing is how you end up shipping a messy V1 that doesn’t actually solve a problem.

A better definition is: MVP exists for learning—getting something into real hands, learning, and iterating. It’s not a synonym for “V1 release.” 2

For uipad, the MVP question became:

“What is the smallest version that helps someone run an in-person event with confidence?”

Not:

“What is the smallest platform that looks like an event platform?”

That’s why the Not‑To‑Do list mattered more than any roadmap.

7) A practical rule I now use as an indie maker

When I’m tempted to add a new feature, I run a simple filter:

Does this strengthen the core promise—or does it create a second product?

For uipad, the core promise is:

Offline-first
Host-ready
Planning + organizing support
Materials you can use in the room

If a feature pulls me toward “live interaction platform,” it’s not a feature request.

It’s a different product.

And as an indie maker, the scarcest resource isn’t time or code—it’s your ability to carry complexity without drowning in it.

Closing: Saying “no” is not limitation—it’s leverage

It’s funny: the moment I started saying no with intention, I felt more confident about shipping.

Because the product stopped being a wish list and started being a tool with a point of view.

uipad has “pad” in the name for a reason.

It’s not a platform.
It’s a planning pad—simple enough to be used, strong enough to carry a real event.

If you’re building your own product, try writing your Not‑To‑Do list before you write another feature.
You might find the product hiding inside the boundaries.

Indie DevLog: UX Patterns for Error Prevention & Minimalist Ledger App Design

Sun, 15 Mar 2026 12:00:00 +0800

While polishing Version 1.0.9 of my indie project, Give & Take (a minimalist ledger and bookkeeping app), I encountered a classic and notoriously difficult UX design challenge.

Many small business owners use my app as a customer balance tracker to manage prepaid memberships and daily consumption. Here is the catch: Bookkeeping is a high-frequency action heavily reliant on muscle memory. Because the app’s core architecture uses a strict “immutable ledger” mechanism (records cannot be edited or deleted to ensure accounting integrity; mistakes require a reverse entry), the cost of user error is exceptionally high.

What happens when an exhausted merchant accidentally records a “Recharge” instead of a “Spend”? To save users from these costly slip-ups, I embarked on a deep UI/UX refactoring journey.

The Anti-Error Dilemma: Friction vs. Flow

Faced with high-frequency user errors, a developer’s first instinct is usually to “add a defense layer”—like a confirmation pop-up before saving, or hiding the input field behind giant “Income” and “Expense” selector buttons.

However, this violates the golden rule of minimalist productivity tools: The Flow. A business owner recording 50 transactions a day does not want to tap 50 unnecessary confirmation prompts. Good error-prevention design (Poka-yoke) should be invisible yet highly effective—pulling users back from the brink of mistakes without adding a single extra tap.

After multiple iterations, I abandoned workflow-blocking interactions and implemented a “Dynamic Visual Impact + Stateful Button” hybrid approach:

Context-Aware Color Shifts: The user’s visual focus is always on the numbers. When the slider switches to “Spend,” the inputted amount instantly turns red and prepends a - sign. Switching to “Recharge” turns it green with a + sign. This leverages peripheral vision for immediate, unignorable feedback.
The Minimalist Black CTA: I initially tried filling the entire “Save” button with bright red or green, but it looked like a blaring panic alarm. The ultimate solution? Keep the button background a premium, brand-consistent black. The error-prevention duty is delegated to a tiny, dynamic color-shifting icon (🟢 / 🔴) on the left, paired with decoupled dynamic text (e.g., Confirm · Recharge).
i18n Pitfall Avoidance: A quick tip for Flutter developers—never concatenate strings like "Save " + variable. It’s a localization nightmare. Using a middle dot (·) or pipe (|) to separate standard verbs and custom nouns looks incredibly sleek and solves syntax inversion in other languages.

This combo adds zero extra taps, yet makes it virtually impossible for users to ignore the nature of their action the moment they hit the keyboard and tap save.

Ditching the “Default”: A Premium Fintech Palette

When first implementing the red/green dynamic inputs, I used standard Material Design Green (0xFF00C853) and Red (0xFFEF4444). Running it on a physical device, it immediately felt cheap—like a generic web game.

Pure neon greens and alarm reds cause severe visual vibration when applied to large typography or button highlights. After studying the color palettes of top-tier Fintech SaaS products like Stripe and Apple Wallet, I completely overhauled the app’s Semantic Colors:

Assets / Income: Replaced with a cooler Emerald (0xFF10B981). It’s restrained, elegant, and carries an expensive “cash-like” quality.
Liabilities / Expense: Softened to a modern Rose (0xFFF43F5E).
Info / Warning: Introduced a clean Modern Blue and a deep Amber, completely avoiding industrial-looking defaults.

By slightly lowering the saturation and tweaking the lightness, even a massive + 100 on a dark-mode background looks incredibly transparent and premium, rather than glaring.

Decluttering Forms: The Art of Subtraction

As features expanded, the “Ledger Settings” page grew increasingly bloated. Explanatory texts and massive status cards squeezed together, forcing users to scroll. To compress the interface back into a single viewport, I applied drastic “subtraction”:

Progressive Disclosure

The form used to be littered with * explanatory notes (e.g., “Modifying the name will sync across all linked contact cards”). I axed them all, condensing the text behind an elegant, minimalist ? tooltip next to the label. Tapping it reveals a dark-themed popup. This single step reclaimed 30% of wasted vertical space.

Rescuing Ugly Dropdowns

The native Flutter DropdownButton destroys minimalist aesthetics. I ditched the default component, opting instead for a PopupMenuButton paired with a custom light-gray, rounded capsule container and an ↕ sort icon. It seamlessly integrates the “Default Action” setting into the form.

State-Driven UI over Spatial Occupation

Previously, a massive white card sat at the bottom of the page solely to house an “Active Status” toggle. It completely hijacked the visual hierarchy. I introduced the semantic design concept of “Archive”: I stripped away the bulky card, turning it into a single line of text and a switch at the very bottom: Deactivate this ledger. The UX magic lies in the linkage: Turning the switch on immediately grays out and disables all input fields above. No extra explanation is needed; users instantly understand the ledger is frozen.

Conclusion

As indie developers, it’s easy to get caught up in the high of “shipping features” while neglecting UI Semantics and user empathy.

This refactoring journey reinforced two core beliefs:

Great design is invisible. It doesn’t force an extra tap for confirmation; it gives you certainty through a touch of Emerald green as you type.
Do not multiply entities beyond necessity. If a disabled state communicates “unavailable,” don’t use blaring red text; if an explanation fits in a ? tooltip, don’t let it hijack the screen.

In the pursuit of perfection, adding features is easy. The true craftsmanship lies in subtraction.

“Good design is invisible; it provides the exact certainty you need, right when you need it.”