Every design system has loading states, error states, and empty states. After years of working with AI products, I’ve found that these three don’t cover what actually breaks in practice.
AI products fail in ways that classical UI doesn’t anticipate. The model is slow in a way that feels different from a network request. The answer is technically correct but incomplete. The agent started doing something and stopped halfway. The user doesn’t know whether to wait, retry, or start over.
These are not edge cases. They’re the default experience of most AI products in production today.
Here are the states I now design for explicitly on every AI project.
Thinking — not the same as loading
A spinner tells the user the system is working. That’s fine for a page load. It’s not enough for an AI generating a response.
The difference is time and expectation. A page loads in under two seconds or something is wrong. An AI might take eight, fifteen, thirty seconds — and that’s normal. A spinner with no context after ten seconds feels like a hang.
What works better: a visible signal that active processing is happening, not just waiting. Some products show partial output as it streams. Others show a brief description of what the model is doing (“Searching your data”, “Generating options”). The specific solution depends on the context, but the principle is the same — give the user a reason to stay rather than a reason to refresh.
Uncertain — the state most teams skip
This is the one I see missing most often.
The model has an answer, but the answer has low confidence. Most products either show it anyway (eroding trust when users eventually notice the quality variance) or suppress it (wasting a potentially useful response). Neither is right.
Users can handle uncertainty if it’s disclosed clearly. What they can’t handle is discovering after the fact that the product was guessing and didn’t tell them.
The design challenge is communicating uncertainty without making the product feel unreliable. A confident caveat is different from an anxious disclaimer. “This is based on 3 of your 47 documents — results may be incomplete” is more useful than a generic “AI can make mistakes” warning that nobody reads.
The framing matters enormously. Users who understand the basis for uncertainty tend to engage more carefully — which is exactly the behaviour you want.
Partial completion — harder than it looks
This one is specific to agentic products where the AI takes actions, not just generates responses.
The agent was asked to do something, started, and stopped. Maybe it hit a permission boundary. Maybe the task was ambiguous. Maybe it completed three of five steps and the fourth failed silently.
The user sees a result that looks complete but isn’t.
This state requires three things the UI often doesn’t provide: a clear description of what was done, what wasn’t done and why, and a path to either continue or undo. Getting any one of these wrong leads to the worst kind of failure — one the user doesn’t discover until it causes a real problem downstream.
I now treat partial completion as a first-class state in any agentic flow, not an afterthought.
Recoverable failure vs. system failure
Classical error states are binary: something went wrong, here’s a message, try again. AI failures are more granular.
Some failures are recoverable by the user — a prompt was ambiguous, a parameter was wrong, the model needs more context. The right response is a clear explanation and an easy path to retry with better input.
Some failures are system-level — the model is unavailable, a data source is unreachable, a token limit was hit. The right response is different: be honest about what happened, don’t ask the user to fix something they can’t fix, offer an alternative if one exists.
Treating these the same way is a mistake I see constantly. Recoverable failures handled as system errors frustrate users who could have fixed the problem in ten seconds. System errors handled as recoverable failures create a loop of failed retries and lost confidence.
The distinction should be explicit in the design system, not left to individual screens to figure out.
Feedback loop — closing the circuit
This one isn’t about failure. It’s about learning.
Most AI products have a thumbs up / thumbs down somewhere. Almost nobody uses it because the cost-benefit is wrong — it costs the user a second, and they have no reason to believe it changes anything.
A useful feedback mechanism is contextual, low-friction, and closes the loop visibly. It appears at the moment the user notices a problem, not at the end of a flow. It takes one tap. And ideally it signals — even minimally — that the input was received and will influence something.
The products that get this right don’t just collect feedback. They make the user feel like a collaborator in improving the tool, which is a fundamentally different relationship.
These states don’t replace the classics. Loading, error, and empty still matter. But if you’re building an AI product and your design system only covers those three, you’re designing for a product that doesn’t exist yet — the version where everything goes right.
The real product lives in the gaps between.
François-Xavier is a senior product designer based in Paris specialising in AI interfaces and complex B2B systems. Available for remote contracts internationally.