Much of digital experience design is built around a scenario in which everything works as expected: the user understands what to do, the system responds correctly, and the task is completed without interruption. This is the familiar happy path, a useful reference for defining and optimizing any flow, although real-world usage conditions tend to introduce many more variables.
A connection may drop mid-transaction, a session may expire, a user may make a mistake, or they may leave a process and return to it later. An external service may also become unavailable, or an AI-powered system may produce an outcome that does not adequately reflect the user’s intent.
At those moments, another dimension of the experience becomes relevant: the product’s ability to help users understand what happened, preserve the progress they have already made, and continue.
❓This raises an interesting question for UX: how can we design products that remain useful when reality deviates from the happy path?
When the journey does not go as expected
Designing the ideal journey helps structure a task, reduce friction, and define what should happen under normal conditions. We can complement this perspective by examining what happens when those conditions change, as interruptions, context shifts, and errors are also part of many real-world experiences.
A failure does not always take the form of an explicit technical error. It can also surface as:
- uncertainty, when a user does not know whether an operation has been completed;
- ambiguity, when system behavior does not match expectations;
- an interruption that forces the user to temporarily abandon the task.
Consider a bank transfer that fails at the final step. Knowing that an error has occurred may not be enough if the user cannot determine whether the funds have left their account, whether it is safe to retry the transaction, or whether they will need to re-enter all the information. At that point, the way the product supports recovery becomes a meaningful part of the experience.
The same principle applies when an ecommerce platform preserves a shopping cart across devices, an application autosaves a form, or a process can be paused and resumed later. These are different scenarios, but they share the same underlying challenge: how to maintain continuity when the interaction no longer follows the expected journey.
Recovery UX: designing for continuity
Treating recovery as a UX capability allows us to move the conversation beyond error messaging. In addition to asking what should we communicate when something goes wrong?, we can examine what information and mechanisms users need to make sense of the situation, regain control, and decide how to proceed.
One dimension is uncertainty. Depending on the context, it may be important to communicate what happened, what the consequences are, which part of the operation was successfully completed, and what options are available next. The effectiveness of an error message depends not only on whether it accurately describes the issue, but also on how effectively it supports the user’s next decision.
Another dimension is progress already made. Preserving entered data, saving intermediate states, allowing users to retry only the failed step, or providing actions such as undo are different recovery strategies that can reduce the cost of a failure. If a form fails on submission, for example, the perceived impact can vary considerably depending on whether the entered information is retained or needs to be entered again.
Recovery can also be considered beyond explicit error states. Concepts such as graceful degradation help us think about which product capabilities should be prioritized when conditions are no longer optimal. With limited connectivity or the temporary unavailability of an external service, it may not be possible to maintain every feature, but it may still be possible to preserve the capabilities required to deliver the core value of the experience.
❓This leads to a useful design question: if something stops working as intended, what needs to remain available for the product to continue delivering value?
Measuring recovery, not just success
Task completion rate tells us how many users reach a goal, but it does not always reveal what the journey was like on the way there.
Two users may both complete a purchase: one without any issues and another after several attempts, a payment failure, and having to repeat part of the process. Both are recorded as successful completions, even though the amount of effort required was very different.
For certain flows, it can therefore be useful to complement success metrics with indicators such as recovery rate, time to recovery, perceived effort, post-failure confidence, or percentage of progress preserved. The appropriate metrics will depend on the product and task, but they introduce another perspective: not only whether the user completed the task, but what happened when they encountered difficulty and what they needed in order to continue.
Unsuccessful journeys can also provide valuable evidence. Abandonments, retries, backtracking, or support contacts can help identify points where recovery is particularly difficult. Combined with qualitative research and other product signals, they can help teams understand which situations generate the greatest friction and where intervention may have the most value.
This perspective also connects Recovery UX with considerations beyond the interface itself, including task completion, conversion, support demand, and trust in the service.
When AI can fail too
AI-powered products introduce additional scenarios into this conversation. In a generative interaction, the system may produce variable outputs, interpret an intent differently from what the user expected, or generate a response that is technically valid but inappropriate for the specific context.
This also broadens the meaning of recovery. When an output is not useful, some experiences may address the issue by allowing users to regenerate the response. In others, it may be more appropriate to correct the system’s interpretation, reformulate the prompt or instruction, undo an action, compare alternatives, or escalate to human intervention.
Consider an AI assistant helping a user resolve an issue with an order. The user asks to change the delivery address, but the system interprets the request as an instruction to cancel the order. In this case, generating another response may not solve the problem. Recovery involves making the system’s interpretation visible, allowing the user to correct the intent before an action is executed, and providing a way to undo the action or escalate to a human if it has already been performed.
These scenarios take on another dimension when AI moves beyond content generation and can execute actions on the user’s behalf. As the system’s level of autonomy increases, design questions around traceability and reversibility become increasingly relevant:
- Can the user understand what the system has done?
- Can they intervene?
- Can they correct a decision or restore a previous state?
It is also useful to consider human-in-the-loop mechanisms from this perspective. Beyond their supervisory role, human intervention can function as one possible recovery mechanism when automation cannot adequately resolve a situation, particularly in higher-impact tasks.
Designing products that can fail gracefully
Thinking about recovery does not mean anticipating every possible scenario or assuming that every source of friction can be eliminated through design. It means acknowledging a straightforward reality: digital experiences also take place under imperfect conditions.
This expands the focus from error prevention to what happens next: what the user understands, how much progress is preserved, what alternatives remain available, and how much effort is required to move forward again.
The happy path remains a fundamental reference for designing a good experience. Looking at recovery adds another perspective: what happens when the assumptions and conditions on which that journey was designed no longer hold.
So, alongside asking how consistently a product works as intended, another question may be equally useful: to what extent does it remain useful when something does not go as expected?
At GammaUX, we work alongside product teams to design and improve digital experiences throughout the product lifecycle, combining research, design, and evaluation to understand not only how intended journeys perform, but also what happens when users encounter errors, interruptions, or unexpected situations. The goal is to help build products that are easier to understand, recover from, and more resilient under real-world usage conditions.
