UX for AI features: waiting, errors and trust

A model-backed feature differs from an ordinary button in three ways: it’s slow, it answers a little differently each time, and it’s sometimes wrong in a confident voice. An interface built by the usual rules ignores all three, and a good model ends up looking worse than it is.

Waiting

A few seconds of a frozen screen reads as a hang. People click again, reload or leave. What helps:

instant response to the click: the button disables, an indicator appears, the request is visibly accepted. A second click must not send a second request;
real stages: if the work happens in steps, show them, like “searching documents,” “writing the answer.” Only actual stages, not decorative captions that rotate on a timer;
a way to cancel: a long generation should be stoppable. It also saves money on answers nobody was going to finish reading.

Streaming

If the output is text for a person, show it as it’s generated. The first words after a second feel faster than the whole answer after eight, even when the total time is the same.

But streaming doesn’t always fit:

if the result is data for the UI (a form, a table, a card), showing half-built JSON makes no sense. Wait and validate;
if the answer has to be checked before display, for disallowed content or format, streaming shows things you may have to take back;
while streaming, don’t jolt the layout. Text should grow downward, not shift buttons out from under someone’s finger.

Errors

Errors in AI features come in two kinds, and it’s worth telling them apart.

Technical: the provider didn’t respond, a limit was hit, the network dropped. Ordinary courtesy applies: a human message instead of an error code, a “try again” button, the input preserved. Few things are more annoying than losing a long request someone spent five minutes typing.

Content: the model answered, but badly. Off topic, inaccurate, wrong tone. Technically everything worked, so the system doesn’t know. That means the person has to tell it, and it has to be easy:

a “retry” button next to the answer;
a way to refine the request without starting over;
a simple “helpful / not it” feedback that you actually read.

Results must be editable

A model’s answer is a draft until the person accepts it. The interface should support that:

generated text opens in an editable field, not in a pretty block you have to copy out of;
part of it can be redone, one paragraph or one field, without rerunning everything;
the previous version doesn’t vanish on retry, since people often liked the first one better;
nothing is sent or saved without an explicit action from the person.

A good sign is when model output and manual input look and behave the same. Then the AI feels like help inside the form, not a separate thing with its own rules.

Trust signals

People can’t see how sure the model is, so give them something to lean on:

sources: if the answer is based on documents, show which ones, linked to the exact place;
an honest label: a short “generated answer, check the important details” next to the result, not in fine print at the bottom of the page;
visible boundaries: if the feature only works with certain data, say so, as in “answering from this year’s knowledge base”;
“I don’t know” as a valid answer: an interface where the model always says something trains people to accept answers they shouldn’t.

What not to do: show confidence percentages the model assigned itself. It looks scientific and means about as much as a random number.

The upshot

The old interface rules still apply to AI features, such as feedback, error handling and user control. The stakes are just higher: the answer is slower, less predictable and sometimes wrong. An interface that’s honest about that beats one pretending everything is instant and flawless.

SUBXCAT can look at the AI features in your product through a user’s eyes and suggest what to fix in the interface.