From clicking through to checking the work

// 7 min read //

I don’t think the interesting part of AI product design is the prompt box.

The prompt box is just the thing everyone can screenshot.

The useful change is smaller and more practical: the product can make the first pass.

Most software still treats the user like a translator for the database. You know what you want, but the product makes you express it in its language: fields, filters, tabs, dropdowns, tables, charts, categories, statuses.

That was always the tax.

The new opportunity is to remove some of that tax. Not by hiding the UI. Not by turning everything into chat. By letting the product draft an answer, show how it got there, and let the user correct it.

That is the part frontend engineers should care about.

Expense entry

Take a corporate card charge after a work trip.

There is already a transaction in the system:

  • Merchant: Uber.
  • Amount: 28.47 EUR.
  • Date: June 3.
  • Card: company card.
  • Receipt: uploaded from email.

The user is not trying to “create an expense.” They are trying to clean up the row enough that finance will approve it.

The old flow is basically clerical work:

  • Match the receipt to the card transaction.
  • Pick the category.
  • Add the trip or project.
  • Confirm whether it was personal or business.
  • Check the tax amount.
  • Add a note because the policy requires one.
  • Submit and hope finance does not send it back.

Some of that work is real judgment. A lot of it is just matching data the product already has.

A better flow starts with a draft:

  • Matched receipt to the Uber card transaction.
  • Suggested category: ground transportation.
  • Suggested report: Amsterdam customer visit.
  • Policy check: amount is within limit.
  • Needs review: project was guessed from the open expense report.

Now the user is not doing data entry. They are checking the work.

That sounds like a small distinction, but it changes the screen. A prefilled form is not enough. The UI has to explain which fields came from the receipt, which came from company rules, which were guessed, and which ones the user changed.

The important state is no longer just empty or filled.

The important state is:

  • filled by the receipt
  • guessed by the system
  • pulled from a rule
  • edited by the user
  • still needs review

If a designer only shows you the happy path, push back. The hard part of this screen is not getting text into inputs. It is helping the user know what is safe to trust.

Filter pages are another place where the old UI makes the user do too much work.

Use a cloud security product as the example.

The user does not really want to operate the vulnerability table. They want to know what to fix first.

In their head, the task is something like this:

Show me the production workloads that are internet-facing, have critical vulnerabilities, and actually have a fix available.

The old page asks the user to break that into the product’s schema:

  • Severity: critical.
  • Runtime status: running.
  • Exposure: internet-facing.
  • Environment: production.
  • Fix available: yes.
  • Asset type: workload.
  • Owner: maybe known, maybe missing.
  • Sort: risk, exploitability, package age, or whatever the product calls it.

At some point the user is not doing security work. They are operating the query builder.

A better page can start from the sentence and return a smaller, more useful set of results:

  • 12 workloads match.
  • 5 are owned by the payments team.
  • 3 have a public exploit.
  • 2 are already covered by a base-image update.

But the page also needs to show what it understood.

This is the part I would want on the screen, close to the results:

Understood: production, internet-facing, running workloads, critical vulnerabilities, fix available.

Assumed: Kubernetes workloads only, because this account has no ECS data.

Not used: owner, because several workloads are unassigned.

That small summary is more important than the input animation.

Without it, the result feels like magic in the bad way. The user cannot tell whether the system understood the request, guessed something reasonable, or silently ignored half of it.

The frontend problem also gets harder. A normal filter page is predictable: selected filters go in, results come out. A natural-language search has extra state hiding inside it.

You need to handle stale responses, edits to assumptions, partial matches, empty results, normal filters as a fallback, and the case where the user changes their mind before the first answer comes back.

The old controls don’t disappear. They move closer to the explanation.

Dashboards

Dashboards have the same problem in a different shape.

Most dashboards answer the product team’s question:

“What metrics can we display?”

The user usually has a more practical question:

“What changed, and should I care?”

The old dashboard gives them twenty-four charts and makes them scan for trouble. Revenue, conversion, traffic, churn, regions, devices, campaigns, errors, cohorts. Everything has equal weight. The user becomes the anomaly detector.

A better dashboard starts with the thing worth checking:

Mobile checkout completion dropped 18 percent this week. The drop started Tuesday afternoon. It is mostly Safari on iOS. The likely cause is the new payment step.

That doesn’t mean you delete the charts.

It means the chart is now evidence, not the opening move.

The user should be able to expand the claim, see the segment, inspect the raw chart, ask a follow-up, dismiss the insight, save it, assign it, or turn it into an action.

This is where the UI gets serious. If the product suggests “rollback the checkout change,” that button needs permissions, confirmation, loading, failure handling, and audit history. A confident sentence is not enough.

The better flow is:

  • First, show the likely story.
  • Then, show the evidence.
  • Then, let the user decide what to do.

That is very different from a wall of charts.

What actually changes

Here’s the practical version.

When you get a design for an AI-assisted flow, don’t start by asking where the prompt box goes. Start with the current workflow. Literally list the clicks.

What is the user doing manually today? Which parts are actual judgment? Which parts are just translating a normal human goal into the product’s internal model?

That gives you a much better set of questions:

  • What work did the user have to do before?
  • Which part can the product draft now?
  • What did the product assume?
  • Where do we show those assumptions?
  • Which assumptions can be edited?
  • What still needs a manual control?
  • What happens when the system is wrong?
  • What action is too risky to do automatically?

That last one matters a lot.

If the product suggests the wrong vulnerability priority, the user wastes time. If it files the wrong expense category, finance sends it back. If it recommends rolling back checkout, being wrong can hit revenue.

The UI has to match that risk.

Sometimes the right interface is a draft. Sometimes it is a warning. Sometimes it is a comparison. Sometimes it is just the old form with two fields filled in and one field clearly marked “please check this.”

The mistake is assuming that “AI UI” means less UI.

It usually means different UI.

Less clicking, more checking. Fewer blank forms, more drafts. Fewer giant filter walls, more visible assumptions. Fewer dashboards that ask the user to find the story, more claims backed by evidence.

That is the before and after I care about.

Not a chat box glued to the side of the page. A product that does the first pass and is honest enough to show its work.