AI loading, streaming and error states that keep users calm

Why AI waits feel longer

In a normal app, most actions finish in a fraction of a second. A save, a page load, a filter. Designers learn to treat waits as rare.

AI features turn that upside down. A model call can take several seconds, and sometimes much longer. The time varies from one request to the next. And the user often cannot tell if the thing is working, stuck or broken.

A well-known guide helps here. Jakob Nielsen wrote about three response-time limits, based on older research: about 0.1 seconds feels instant, about 1 second keeps the user's train of thought, and about 10 seconds is where attention starts to drift. Many AI responses cross the second and sometimes the third. So the screen has to do more work to keep people patient.

The aim is not to hide the wait. It is to show that something is happening, to give the user something useful to read or do, and to be honest when something goes wrong. These are the AI product UX states that decide whether a feature feels solid or flaky.

Streaming text

Streaming means showing the answer as it is written, word by word, instead of waiting for the whole thing. It is the most common way to make a long answer feel faster. The first words appear in a second or two, and the user starts reading while the rest arrives.

It works, but it has details:

• Show a "thinking" state before the first word. A short pause with no feedback feels like a freeze. A small animated indicator or a line such as "Looking at your data" is enough.
• Do not make the text jump. As new text arrives, the page should not scroll away from what the user is reading. If they have scrolled up, leave them there, and offer a "Jump to latest" control.
• Handle formatting as it arrives. If the answer uses lists, code or tables, half-written markup can look broken for a moment. Decide how to render partial content so it does not flicker.
• Give a stop button. Users should be able to cancel an answer that is going the wrong way. Keep what has been written, so they can still use it.
• Show when it is done. A clear change, such as the stop button turning into a retry, tells people the answer is finished. Action buttons like copy and retry can appear only at that point.
• Think about screen readers. Announcing every new word through a live region is unusable. A better way is to announce that the answer is being written, and then that it is ready. Test with real assistive technology.

Respect reduced motion too. A typing animation that fakes streaming for an answer that is already complete is a design choice, but if someone has asked their system to reduce motion, show the answer at once.

Progress for long tasks

Some AI tasks take much longer than a chat answer: analyzing a large file, running several steps, generating a report. A spinner for thirty seconds or more is not enough.

Better options, from simple to more involved:

• Name the steps. "Reading the file", "Checking totals", "Writing the summary". Seeing movement between steps is calming, and it shows the user what the system is doing.
• Show real progress where you can. A progress bar only helps if it reflects something true. A bar that sticks at 90% for a minute damages trust. If you cannot measure, show steps instead of a percentage.
• Give a time hint only if it is honest. "This usually takes about a minute" is useful if it is typically true. Do not guess.
• Show partial results. If the system finds things one at a time, let the user read the first ones while the rest continue.
• Let people leave. For jobs over a minute or so, allow the user to go elsewhere and notify them when it is done. Make sure the job is not lost if they close the tab.
• Allow cancelling, and say what happens to work already done.

Timeouts and retries

Model calls fail. The service is busy, the network drops, the request takes too long. Plan for it.

• Retry quietly, once. Many failures are brief. An automatic retry can fix them without bothering the user. Do not retry endlessly.
• Set a visible limit. Decide how long you will wait, and what the user sees when that time is up.
• Keep the user's input. After a failure, the question the user typed must still be there. Losing it is the fastest way to make someone angry.
• Keep what was already received. If a stream stopped halfway, show the part that arrived and say it stopped.
• Offer a clear next step. A "Try again" button, and if it keeps failing, a way to contact support or check status.
• Tell the difference between kinds of failure. "We could not reach the service" and "That file is too large" call for different actions.

Wrong or empty answers

Not every failure is technical. Sometimes the model works fine and the answer is bad. It may be wrong, empty, off-topic, or a refusal.

• Empty answers. If there is nothing to say, say so, and explain why if you know: "I could not find any orders from last week." Then suggest a next step, such as widening the date range.
• Refusals. If the product will not do something, be clear and brief about it, without lecturing. Point to what it can do.
• Wrong answers. You will not catch them all, so make it easy for users to notice and to react. Show sources, allow edits, and make retry and rephrase obvious. Add a simple way to report a bad answer.
• Uncertain answers. If the system has a real signal about confidence, show it in plain words. If it does not, do not invent one.

The main rule: never show a failure dressed as a success. An empty result that looks like a normal result, or an error message inside a chat bubble that looks like an answer, will mislead people.

Copy for each state

Short, plain text does a lot of work in these moments. Here are examples of the tone we aim for.

Avoid apologizing in every message, and avoid cute phrases for errors. Be direct, say what happened, and say what the user can do.

Test it with slow and broken conditions

These states are easy to skip because they do not appear in a demo. To check them, slow your network to a poor connection, force a timeout, return an empty result, and cut a stream halfway. Watch what the screen does. Then watch someone else use it.

We design these states as part of our AI product design work, and you can see what we build for ourselves in the Lab. If you have an AI feature that feels flaky, send us a recording of it in a slow moment through a free design review. We will tell you which states we think are missing.