Articles

From failure to recovery in UX use cases

Reliable services are judged as much by their recovery paths as by their ideal journeys. Connections drop, sessions expire, payment details fail, and records cannot be found. Australian users commonly move between mobile banking, tap-to-pay, government portals, and booking apps during busy days in Sydney, Melbourne, or Canberra, so recovery must survive device changes and interrupted connections.

Writing use cases for error handling and recovery scenarios makes those moments explicit. It gives designers, developers, content specialists, and support teams a shared account of what the person was trying to achieve, what went wrong, and how they can continue safely. In UCDmanager, these flows can sit beside personas, user roles, requirements, and accessibility findings, forming a traceable record instead of a collection of isolated error screens.

Start with the failure, not the screen

Start with the user's intent, not the screen that displays the error. For example, updating a delivery address is a goal; “postal code validation failed” is a condition within that goal. Name the actor, trigger, preconditions, expected outcome, and the point at which the flow can safely resume. This framing keeps the scenario useful when an interface, payment provider, or backend service changes.

Then distinguish the failed attempt from the recovery attempt. Record what the user saw, what information remains valid, whether the action can be retried, and what evidence confirms success. Link the alternate path to the main use case so testers can trace both behaviours. UCDmanager's common user questions can help teams confirm how projects and documentation features fit together before they formalise a scenario.

Separate recovery paths by cause

Not every message needs a unique flow, but each cause demands a different response. Input errors should preserve entered values and identify the field to change. Authentication failures should offer a safe sign-in route without exposing account information. Dependency failures, such as an unavailable payment service, need a clear status, a realistic retry, and an alternative such as saving the order for later. A rejected transaction may require a different payment method or customer support, not another blind retry.

Give alternate flows specific entry and exit conditions. A shopper in Brisbane whose online marketplace order cannot be submitted should not be told simply to try again: the use case should state whether the basket is retained, whether stock is rechecked, when the card is charged, and how an Australian consumer can cancel or obtain a refund under the Australian Consumer Law. Small businesses and not-for-profits using the same service may need plain export and reconciliation steps rather than a consumer checkout.

Core elements of a recovery flow

A concise scenario can contain four operational elements without becoming a design specification. Include only what a team needs to design, build, and test the recovery path.

Use each element to remove ambiguity. If an upload fails on a regional mobile connection, the visible state should distinguish a temporary network problem from an invalid file. The action should retain the document, explain whether it is safe to retry, and avoid asking the user to re-enter information. Completion evidence might be a reference number, a confirmation message, and a support escalation path.

Design messages that preserve trust

Error copy is part of the use case, not decoration. State what happened, whether the user lost anything, and what they can do next. “Something went wrong” hides the recovery decision; “We couldn't save your form. Your answers are still here” supports it. Put the action in the primary action button and keep the cause nearby when it helps, such as an incorrect postcode or a temporarily unavailable service.

Accessibility constraints belong in the same flow. A person using a screen reader needs the error state announced and focus moved to the relevant field or alert; a keyboard user needs an obvious route past a failed submission. Australian Government digital services are assessed against the Digital Service Standard, including WCAG 2.1 AA requirements, so document expected focus order, text alternatives, and non-colour cues rather than treating them as final QA checks.

Privacy and security also shape the message. If personal or health information is involved, and the Privacy Act 1988 applies, the flow should reflect the Australian Privacy Principles by collecting only what is necessary and avoiding details that could reveal hidden records. A flow for an expired My Health Record session, for instance, should prompt renewed authentication without displaying a patient's name or test result in an error message.

Validate recovery with Australian users

Validate the scenario with people who hold the relevant roles: a customer, support adviser, service operator, content designer, and developer. Ask each person to explain the goal and recover without being told which button to press. That reveals whether the trigger, status, and choices form a coherent journey. Patterns and terminology can also be compared with peers in the design community forum.

Run the scenario against realistic service conditions, including intermittent connectivity between metropolitan and regional Australia, an expired session, and a dependency that remains unavailable. Check that entered data is retained where safe, retries cannot create duplicate bookings or payments, and escalation details reach a human channel. Support staff need the same sequence documented, since their advice becomes part of the customer's experience.

A traceable recovery flow gives teams a shared definition of what happens after failure. It also lets acceptance criteria describe safe completion rather than merely the absence of an error. With personas, user roles, and test evidence connected in UCDmanager, the use case becomes a durable design artefact that can guide interface decisions, operational training, and future service changes.