Imagine submitting a long application and seeing “Something went wrong.” The button is available again. None of the information on the screen tells you whether the application was saved, submitted, or lost.
That is not just an unhelpful message. It is an unresolved product decision exposed to the customer.
We like to discuss failure states early because they force useful questions about ownership, persistence, and recovery. The answers often change the successful journey too.
Tell the user what is known
An error message should not claim more certainty than the system has. If the product knows that a file was rejected because of its format, it can explain what to change. If it does not yet know whether a submission completed, a generic invitation to try again may be misleading.
Separate those situations in the design. A rejected input, an unavailable service, and an uncertain outcome call for different next steps. Give each state a meaning that engineering and product can test together.
For the application example, useful information could include whether the draft is preserved, whether submission is still being checked, and how the person can return later. The wording depends on actual behaviour; copy cannot compensate for a system that does not preserve the work.
Make recovery part of the original scope
A retry button is only useful if retrying is an appropriate action. A support link is only useful if support can identify the problem. An option to return later is only useful if the user can find the same application again.
Trace each proposed recovery path until it reaches a real resolution. If it ends with an employee manually querying an unfamiliar database, include the operating work and access requirements in the discussion.
This does not mean building a control for every theoretical failure. Prioritise the cases that prevent important tasks, lose work, or leave users uncertain about consequential actions. Use the product's real dependencies to choose those cases.
Test the conversation, not just the component
Ask someone unfamiliar with the implementation to attempt the task while a dependency is deliberately unavailable in a test environment. Observe what they believe happened and what they try next.
A technically correct message may still leave the wrong impression. “Request accepted” can sound like completion when it only means the request entered a queue. “Session expired” can leave someone unsure whether their work survived.
Review the journey after recovery as well. Does the customer receive duplicate notifications? Do they see an outdated status? Can they distinguish the original attempt from the successful one?
The successful screen is usually easy to explain. A thoughtful recovery path shows whether the team has understood the entire task. Designing it early is a practical way to find missing product decisions while they are still inexpensive to discuss.