Your AI feature works. It returns a good answer in eight seconds. The problem is that for those eight seconds the user stares at a spinner that never changes, decides the thing is stuck, and closes the tab. Good AI loading states design is what separates a feature that feels slow but trustworthy from one that feels broken. The latency is rarely the real issue. The silence during the latency is.

Most teams treat loading and feedback as decoration they bolt on at the end. For a model-backed feature that is a mistake, because a slow response with no feedback reads as a failure, and a failure that users blame on your product is a feature they stop opening. This is the same lever behind the AI UX patterns that drive feature adoption: the interface around the model decides whether people keep using it. Here is how to design loading and feedback so a slow model response feels intentional instead of dead.

Why AI loading states design is different from normal loading

A model call has no fixed duration. That single fact breaks most of the loading advice you have read.

Classic web performance assumes deterministic timing. You know roughly how long a page or query takes, so you can budget for it. Nielsen Norman Group's long-standing research on response times sets three perception limits that still hold: 0.1 second feels instantaneous, 1 second keeps the user's flow of thought uninterrupted, and 10 seconds is the limit for keeping the user's attention on the task. Google's RAIL model extends this into engineering budgets, noting that users expect different things from each phase of an interaction and that goals should be set per context. Both assume you can predict the wait.

A large language model call routinely blows past the 10-second limit, and you often cannot predict by how much. Token generation is variable, retries happen, and a long prompt can double the time of a short one. So the deterministic budget is the wrong frame. The right frame is: you cannot promise speed, so you must instead make the wait legible. That shift is the whole job.

Ten seconds is "about the limit for keeping the user's attention focused on the dialogue." Past that, people start switching to other tasks. Most AI calls live on the wrong side of that line.

What feedback should an AI feature give while it works

In-progress feedback has three jobs: confirm the system received the request, signal that work is happening, and set an expectation for how long it will take. A bare spinner does only the second, weakly, which is why it reads as "stuck."

Map the feedback to the perception thresholds:

• Under 0.1 second: acknowledge the action. A button state change or a cursor is enough. No spinner.
• Around 1 second: show that the system is working. A spinner or skeleton is fine here, because the user has not started to doubt yet.
• Past a few seconds: narrate. Replace the silent spinner with status that changes ("Reading your document," "Drafting a summary"). Movement that reflects real stages is what keeps trust alive.
• Past 10 seconds: estimate or stream. Give a sense of how much is left, or start showing partial output so the wait becomes productive.

The failure pattern is using the same one-second treatment for a fifteen-second wait. The user has no signal that anything is still happening, so they assume nothing is.

How do you design loading states for slow AI

Design loading states for slow AI by routing each request to a pattern based on its latency tier, not by picking one spinner for everything. Decide the tier, then decide the treatment. This is the core of designing for AI uncertainty: you cannot remove the variability, so you design the interface to absorb it.

Here is the decision in code form. Treat it as the routing logic behind your loading layer, not literal syntax:

function loadingPattern(expectedLatency, canStream):
  if expectedLatency < 1s:        return "instant feedback (no spinner)"
  if expectedLatency in 1..4s:    return "spinner or skeleton"
  if canStream:                   return "stream tokens as they arrive"
  if expectedLatency in 4..10s:   return "staged status messages"
  if expectedLatency >= 10s:      return "progress estimate + cancel"
  else (unknown):                 return "staged status + cancel + timeout"

The most important branch is canStream. If your model returns tokens incrementally, streaming them turns a ten-second wait into a response that starts in one second and finishes while the user is already reading. Streaming is the single highest-leverage move in slow-AI loading because it collapses perceived latency without making the model faster.

When you cannot stream, the fallback is staged status that reflects real backend steps. Fake progress that does not map to anything erodes trust the moment the bar stalls at 90 percent.