Failure Modes as First-Class UI States
Explore how to recognize and represent different AI failure modes as explicit UI states to improve user experience. Learn to handle timeouts, network errors, partial responses, and invalid data separately, ensuring the UI provides clear feedback, preserves data, and guides user recovery actions.
A user sends a message in a chat UI, the assistant bubble appears, and then nothing changes. No typing indicator, no error copy, no button, just a blank or half-filled space that looks like it might still be working. After a few seconds, the user sends the message again, which can create duplicates, conflicting replies, or a second failure with no explanation.
This lesson stays at the level of user-visible behavior and the product contract, not transport implementation details. The same blank bubble can hide three very different situations underneath it.
Unlike a normal form submit, a generative turn can fail in ways that produce the same visual symptom. Slow generation is non-terminal and should keep the user oriented. A timeout is terminal for that attempt and needs a recovery path. A network error is terminal and can invalidate whether the server saw the request at all. Treating all three as the same blank bubble forces the UI to guess, and the user pays for that ambiguity.
Define failures by what the UI can observe
With the ambiguity established, the next step is to name failures only using signals the frontend can reliably see. Each failure mode becomes a state in your component, ...