A customer can learn more about your digital experience from one failed click than from twenty successful ones.
They are halfway through something that matters. An application. A payment. A booking. A form that took ten minutes to complete.
They click Submit.
Instead of confirmation, they get:
Something went wrong. Please try again later.
For the system, this may be one failed transaction among thousands. For the customer, the situation is suddenly much larger.
Did the payment go through? Was everything they entered lost? Should they click again? Could clicking again make the problem worse? How long is "later"? And if the screen cannot answer those questions, who can?
Most digital journeys are designed for forward motion. But the moment a customer cannot move forward is often the moment that decides whether they still trust the organization. That is a mistake most teams only discover after the fact.
This is where a Digital Navigator mindset matters: connecting technology decisions to the human experience they create, and translating complex digital operations into something customers can understand and act on. Error states are where that principle becomes unusually visible.
The happy path shows whether a product works.
Failure shows whether the organization knows how to help.
An Error Has Two Meanings
Inside the organization, a failed interaction may have a precise technical description.
An API timed out. Validation failed. Authentication expired. A downstream service became unavailable. An unexpected exception interrupted the request.
Those distinctions matter to the people diagnosing the system.
The customer is diagnosing something else.
"Did my payment go through?"
"Did I lose everything?"
"Have I done something wrong?"
"Should I try again?"
"Will trying again create two orders?"
Technical teams naturally focus on cause because cause determines the fix. Customers focus on consequence because consequence determines their next decision.
A good digital service has to serve both realities at once.
That means an error message cannot simply translate an internal event into slightly friendlier language. "Authentication failure" becoming "We couldn't authenticate you" changes the vocabulary without solving the uncertainty.
The useful question is different:
What does this person need to know before they can safely decide what to do next?
That shift sounds small. It changes the entire job of the error state.
Failure Puts the Whole Experience Under Pressure
Successful journeys can hide weak design surprisingly well.
When every service responds, every field validates and every integration behaves as expected, the customer rarely needs to understand how the experience is assembled.
Failure removes that protection.
Suddenly it becomes obvious whether entered information has been preserved. Whether the system knows enough context to offer useful guidance. Whether support can see what just happened. Whether the interface can explain the problem without exposing the machinery underneath it.
An error state is a stress test for the relationship between technology, process and customer experience.
Imagine two customers whose file upload fails at 95 percent.
The first sees:
Upload failed. Try again.
The second sees:
We couldn't complete the upload. Your project details have been saved, so you won't need to enter them again. Check your connection, then retry the file.
The technical failure may be identical.
The experience is not.
The second design answers the question that frustration makes urgent: How much of this do I have to do again?
Or consider a payment failure arguably the moment when uncertainty carries the highest stakes:
We couldn't confirm your payment. You have not been charged. Your order is saved for 20 minutes, and you can safely try another payment method.
That single message answers the three questions a customer actually has in that moment: What happened? Did it cost me anything? What can I safely do now?
A system earns trust partly by working reliably. It also earns trust by behaving coherently when reliability runs out.
Design Around the Customer's Next Decision
When something fails, the customer immediately becomes a decision-maker. They have to decide whether to wait, retry, restart, switch payment methods, contact support or abandon the journey entirely.
Good recovery design reduces the uncertainty around those decisions.
Start with four pieces of information.
Tell them what happened. Use language that helps the customer understand the situation rather than language that describes the system. An error code can be useful as a reference. It should rarely be the explanation.
Tell them what did and did not happen. This matters especially when the action has consequences. If a payment was not taken, say so. If an application was saved but not submitted, make that distinction clear.
Preserve their work. A temporary technical failure should not become a penalty paid in the customer's time. Keep form entries, selections, uploads and progress wherever the system safely can.
Give them a viable next action. "Try again" only helps when the condition is likely to change for example, a temporary connection issue or an expired session. If the same system dependency is still unavailable, the product is asking the customer to repeat the same experiment and hope for a different result.
A useful way to think about this is the Recovery State Model: explain the situation, clarify the consequence, preserve the customer's work, offer a safe next action, and carry context into assisted service.
And when self-service reaches its limit, provide a path to a person.
That handoff should carry context with it.
A customer who has spent fifteen minutes completing a failed process should not then spend another ten reconstructing it for support.
The goal is not a nicer error message.
The goal is a credible route from failure to recovery.
Error States Are Where the Org Chart Leaks Onto the Screen
Poor error experiences often reveal something deeper than weak interface design.
They reveal organizational boundaries.
Product owns the interface. Engineering owns system behavior. Operations owns the process. Customer service owns the complaint. Another team owns the external platform that actually failed.
Internally, those boundaries can be perfectly reasonable.
Customers have no reason to care about them.
They experience one organization.
This is why some error journeys feel strangely fragmented. The interface says one thing. The support agent sees another. The backend knows the transaction status, but the front end cannot display it. The customer is told to contact a department that then asks for information the system already has.
Failure acts like an organizational X-ray.
It reveals where ownership stops, where information stops moving and where one team's finished job becomes the customer's unfinished problem.
That makes error recovery an interdisciplinary design problem. Rewriting copy may help at the surface, but meaningful improvement can require changes to data flows, service processes, system states, escalation rules and ownership.
The error message is sometimes the smallest part of the error.
Measure What Happens After the Failure
Digital teams are good at measuring successful outcomes.
Completion. Conversion. Adoption. Transactions.
Those metrics describe what happened when the journey worked.
Recovery needs its own questions.
How many customers successfully finish after encountering a recoverable error? Where do they abandon? Which failures generate support contacts? How often does someone have to repeat information? Which errors create the greatest disruption to commercially important journeys?
These questions matter because technical frequency and customer impact are not the same thing.
A frequent but harmless error may deserve less attention than a rare failure that leaves a customer unsure whether several thousand euros have been charged.
The useful unit of prioritization is not simply the number of exceptions.
It is the consequence of the exception.
One practical measure is recovery completion rate: the percentage of customers who encounter a defined failure and still complete the intended task within a meaningful recovery window.
That metric changes the conversation. Teams stop asking only, "How often does this break?"
They also ask, "When it breaks, can people get back?"
Design Failure Before It Happens
Error handling often arrives late in delivery.
The main journey is designed. The integration is built. Acceptance criteria are nearly complete.
Then someone asks what the screen should say if the request fails.
By that point, many of the important recovery decisions have already been made indirectly. Perhaps the system cannot preserve the form. Perhaps transaction status is not available to the interface. Perhaps support receives no context. Perhaps retry behavior was never defined.
A better approach is to design failure alongside success.
For every important step in a customer journey, ask:
What can fail here?
What will the customer know when it does?
What information can be preserved?
What can they safely do next?
What happens if self-service recovery fails?
What context needs to follow them into assisted service?
How will the team know whether recovery worked?
These are product questions, architecture questions, service questions and customer-experience questions at the same time.
That is precisely the point.
Designing the successful path tells the system where the customer should go.
Designing failure determines whether the customer can still get there when reality refuses to cooperate.
The Moments Outside the Happy Path Still Belong to You
Return to the customer who clicked Submit.
The technology failed for a moment. That part may have been unavoidable.
What happens next is much more likely to be a design decision.
The interface can leave them uncertain or give them context. It can erase their work or preserve it. It can push responsibility back onto them or offer a useful next step. It can send them to support empty-handed or carry the history of the failed journey with them.
Customers do not stop being customers when an API times out, a transaction fails or a service becomes unavailable.
Those moments still belong to the experience.
And they often reveal more about the organization behind that experience than the polished screens that came before them.
Do not only design for the customer who clicks "Continue" and reaches the next screen. Design for the customer who clicks and suddenly can't.