Designing Loading and Error States for AI Features

Most loading and error advice assumes a predictable system. You click, the server answers in 200 milliseconds, or it fails with a clear reason. AI features break that assumption.

Responses can take two seconds or forty. They can arrive in pieces. They can fail halfway. And they can succeed technically while being useless. If you design these features with a normal spinner and a normal red banner, users will be confused, and I think they'll quietly stop trusting the product.

I'm a product designer, not a machine learning person, so this post is about the interface, not the model. Here is how I'd think about it.

01The core problem: the wait has no shape

A normal page load has an implied length. Users have a rough sense of how long a table takes to appear. With AI, they don't know if the thing is thinking, stuck or broken.

So the job of a loading state here is not just "show something is happening." It is to answer three questions:

• Is it working?
• Roughly how long will this take?
• Can I do anything else meanwhile?

A bare spinner answers only the first, and badly, because it looks identical whether the wait is two seconds or two minutes.

02Loading states: pick by the shape of the output

Streaming text

If the output is text someone can read as it arrives, stream it. The first words appearing is the best progress indicator there is. It proves the system is alive and gives the user something to do.

Two details I'd care about:

• Don't let the layout jump as text grows. Reserve space or let the container grow downward without pushing controls around.
• Keep a visible "Stop" button while streaming. Users should be able to cancel a response that is going the wrong way.

Whole-result output

Some results are only useful complete: a generated layout, a classification, a data summary. Streaming half of it would be noise.

For these, use a labeled state rather than a spinner. "Analyzing your 3 files" says more than a rotating circle. If the process has real stages, name them. If it doesn't, don't invent fake stages to look busy. Users notice when a progress bar is theater.

Long waits

Say a feature might take over ten seconds. At that point I'd do three things:

1. Set an expectation up front ("This can take up to a minute").
2. Let the user leave and come back, with the result saved.
3. Notify them when it's done, if that fits the product.

Making someone stare at a screen for a minute is a design failure, not a model limitation.

03Error states: the failure types are different

A normal error state usually covers one case. AI features have at least four, and they need different messages.

1. The request failed

Network drop, timeout, server error. This is the familiar one. The rules are familiar too: say what happened, keep the user's input, offer retry.

The most important thing here is never lose the prompt. If someone typed three paragraphs and the request fails, an empty input box is a small disaster. Preserve it. This is the same principle I wrote about in multi-step forms with saved state: effort the user already spent is not yours to throw away.

2. The request was refused or limited

Rate limits, content rules, usage quotas. These are not "errors" in the user's mind, they are rules. Treat them that way.

Say which rule applied and what to do. "You've used all 20 generations for today. Resets at midnight." beats "Request failed." If the cause is content policy, be calm and specific rather than accusatory.

3. The response broke partway

Streaming adds a failure that normal requests don't have: the answer stops in the middle of a sentence.

Don't leave a truncated answer looking finished. Mark it clearly ("Response was interrupted") and offer "Continue" or "Try again." A silently cut-off answer is worse than an error, because the user may act on it.

4. The request worked and the answer is bad

This is the one most teams don't design for. The system returned 200 OK, and the output is wrong, empty, off-topic or confidently made up.

No error will fire, so the interface has to give the user an exit. I'd always include:

• Regenerate, for "try again."
• Edit your prompt, for "I asked badly."
• Edit the result directly, where it makes sense.
• A way to flag it, even if it's just thumbs down with an optional reason.

If the bad-answer path is hidden or awkward, users learn that the product can't be corrected, and that's when trust drops.

04Write the copy like a person

Error copy for AI features tends to go wrong in two opposite ways: robotic ("An unexpected error occurred") or overly cute ("Oops, my brain glitched!"). Both avoid saying anything useful.

A simple structure works:

• What happened, in one plain sentence.
• Whether the user's work is safe.
• What they can do next.

Compare "Something went wrong" with "We couldn't finish this summary. Your document is still saved. Try again, or use a shorter section." The second is barely longer and removes the guesswork.

Also avoid language that implies the AI has feelings or intent, like "I'm sorry, I couldn't understand you." It sets expectations the product can't meet, and it makes failures feel personal.

05Be honest about uncertainty

Loading and error states are where a product is most honest, or least. A few things I'd want in any AI feature:

• Label generated content as generated, so users know to check it.
• Don't show a confidence indicator unless it actually means something. A made-up "92% sure" badge is worse than none.
• Make sources or inputs visible when the feature uses them, so users can verify.

The goal isn't to scare people. It's to make checking easy, so the cost of a wrong answer stays small.

06Accessibility is part of the state

Dynamic states are easy to make invisible to people using screen readers. Streaming text and status changes need to be announced in a way that doesn't flood the user. In practice that usually means a polite live region for status messages ("Generating", "Done", "Failed") rather than announcing every token. Errors should move or announce focus clearly so the retry action is reachable by keyboard.

I'd test this by actually tabbing through the failure states, not just the happy path. If you're newer to focus handling, my modal focus and ARIA walkthrough covers the basics.

07A checklist before you ship

• Does the loading state tell users it's working and roughly how long?
• Can they cancel?
• Is their input preserved on every failure?
• Do the four failure types have different messages?
• Is there a visible path when the answer is bad but technically successful?
• Is a truncated response clearly marked?
• Is generated content labeled?
• Do status changes work with a keyboard and screen reader?

If you can only fix one thing, fix the fourth failure type. Everyone designs for the crash. The product earns trust in how it handles an answer that is simply wrong.

08Frequently asked questions

Should an AI feature show a spinner or stream the response?

Stream when the output is text the user can start reading, because partial content shows progress and lowers perceived wait. Use a labeled progress state when the result only makes sense whole, such as a generated layout or a summary that must be complete to be useful.

How should an AI feature show that it failed?

Say what happened in plain words, keep the user's input, and offer a next step like retry or edit. Don't use a generic "Something went wrong" and don't blame the user for a failure on your side.

Do I need a separate state for a bad AI answer?

Yes. A request can succeed technically and still return something wrong, empty or off-topic. Give users a way to regenerate, edit or report it, and keep that path as visible as the success path.