“Something went wrong” describes the software’s feelings, not the user’s situation. A useful error state explains what failed, what remains safe, and what the person can do next.
The best error handling begins before the message is written. The system needs enough structure to distinguish a temporary network problem from invalid input, missing permission, unavailable data, or a bug.
Preserve context
Errors are most helpful beside the action or content they affect. A field error belongs with its field. A failed upload belongs with that file. A page-level service outage can use a larger status panel because the whole task is affected.
Moving every failure into a global toast removes context and often disappears before the user has decided what to do. Toasts work better for confirmations or background events that do not require careful recovery.
Say what happened in plain language
Useful copy follows a small pattern: the action that did not complete, the likely reason when it is known, and the next available choice. “We couldn’t save this draft because the connection was interrupted. Your changes are still on this device. Try again when you’re online.” is longer than “Save failed,” but it answers the questions that matter.
Technical details can live behind a disclosure or a copyable reference code. They should not replace the human explanation.
Match the action to the failure
A Retry button only helps when repeating the request can succeed. Permission errors need a path to settings or an administrator. Validation errors need correction. Missing content may need navigation back to a valid parent page.
When recovery is impossible, be honest and protect what can still be protected. Offering an export or copy action can prevent a service failure from becoming lost work.
Design the state before it happens
I include empty, loading, partial, offline, permission-denied, and failed states while designing the main screen. This exposes missing product decisions early and prevents the error interface from becoming an unstyled exception at the end.
A good error state does not pretend failure is pleasant. It reduces uncertainty, preserves trust, and helps the user regain control with the fewest possible steps.