The Output Is Empty. Now What? Designing Failure States for AI Tools
A failure-state field guide for AI-made tools: empty input, weak evidence, timeouts, partial results, unsafe requests, and recovery without blame.
The happy path makes an AI tool look intelligent. The failure path shows whether the product understands its job. When a result is empty, delayed, or uncertain, a generic something went wrong message throws away the context the user already supplied.
Useful failure states do three things in order: say what happened in language the visitor can recognize, preserve as much work as possible, and offer a next action whose outcome is different from pressing the same button again.
Empty input is instruction, not an error
If a required field is empty, the interface already knows the remedy. Say what belongs there and give a short example near the field. A toast at the opposite edge of the screen makes the visitor search for a problem the product can identify precisely.
Validation should happen before an expensive request. It is faster for the visitor and avoids consuming service capacity on input the interface knew was incomplete.
Weak evidence needs a different response
A research tool may receive valid text that cannot support a confident conclusion. Returning a polished answer anyway is more dangerous than returning nothing. The right state is not error; it is insufficient evidence, followed by the specific details that would improve the analysis.
This is where trust becomes visible. A tool that can say the notes contain preferences but no purchase behavior is more useful than one that assigns a confident score to every paragraph.
Timeouts and partial results
A timeout is a technical condition, so the page should preserve input and say whether a request may still be processing. If some sections are available, show them as partial rather than discarding everything. Mark missing sections clearly; do not let the visitor mistake an incomplete result for a complete one.
| State | Preserve | Offer |
|---|---|---|
| Empty required field | Other completed fields | Focus and example |
| Weak evidence | Input and cautious findings | Specific evidence request |
| Timeout | All input | Retry with status |
| Partial result | Completed sections | Resume or retry missing section |
| Unsafe request | Non-sensitive draft when appropriate | Boundary and safer alternative |
Do not blame the visitor
Invalid prompt, bad request, and user error describe the system's perspective. The visitor needs to know which part can be changed. Plain language is not cosmetic here; it is the shortest route back into the workflow.
A final check is to read the error after imagining twenty minutes of lost work. If the message sounds cheerful, vague, or evasive in that context, revise it. Recovery copy should be calm enough to carry frustration without pretending nothing happened.