A branching route leading to a manual form and a pause symbol beside a gold lifebuoy.
Design & UX,  Product Management,  Tech & Cybersecurity

When an AI feature fails: design a recovery route users can understand

An AI feature proposes a helpful answer. Then it cannot produce one, gives an uncertain result or stops halfway through. What can the person using it do next?

A recovery route is the path someone can take when the normal experience fails. For an AI feature, that might mean keeping a draft, choosing a manual method or asking for qualified help. Designing this route is part of defining the product, not just writing an apology.

This guide uses a fictional volunteer-rota assistant that proposes shifts for an organiser to review. It does not send messages or change a live rota automatically. The example keeps the focus on clear recovery decisions, rather than trusting AI to manage commitments.

Name the failed task

“AI unavailable” describes a component. “We could not generate a rota suggestion” explains the task. Add what is known about the person’s work: are their entries retained, has anything been saved, and has anything been sent? Only make those statements when the product can verify them.

A useful recovery message tells someone what happened, what remains intact and the next available action. If completion is uncertain, say so and provide a way to check. Do not show a confident failure message when a request might actually have completed.

1. Separate three failure situations

Purpose: Avoid offering the same remedy for different problems.

Unavailable: the suggestion could not be generated. Unusable: an answer arrived but violates a stated rule, such as assigning a volunteer outside their availability. Uncertain: the system does not yet know whether the request completed. Each situation needs a different next action.

For the fictional rota tool, an unavailable result can offer a manual draft. An unusable result should explain the rule needing review. An uncertain save should allow the organiser to check the existing draft before repeating an action that could create a duplicate.

2. Keep a useful manual route

Purpose: Help someone complete the job without reconstructing everything.

If the organiser has already entered availability, preserve that work where the product supports it. Offer a blank rota they can fill from the same entries. Do not call the route “manual” if it hides another AI request or requires an unavailable service.

Decide what happens to incomplete suggestions. They should remain clearly labelled and separate from an approved rota. An organiser must be able to understand which information is confirmed, which is suggested and what will happen when they save.

Choose the recovery message

Fictional situation: rota generation failed before a suggestion was created. Availability entries remain on the page. No draft was saved. Which message helps the organiser continue?

Message A: Something went wrong. Try again.

This does not explain the state of the work or offer an alternative. Retrying may be useful, but it should not be the only path if the person needs to complete the rota now.

Message B: We could not create a rota suggestion. Your availability entries are still here. Create a manual draft or try generating again.

This is more useful for the stated example because it explains the failure, confirms a known state and names two actions. Use it only if the system can actually preserve those entries and provide both routes.

3. Make recovery understandable and accessible

Purpose: Keep the next step available to more people.

Write errors in text rather than relying on a red icon or colour. For form input errors, identify the relevant field and describe the problem. Check that people can reach the recovery controls using a keyboard and understand status updates with their assistive technology.

Test with the actual interface and appropriate accessibility checks. A well-written message alone does not establish accessibility compliance. Ask people to explain what they think was saved and what the next button will do; their interpretation can reveal gaps in the wording.

Assign ownership before launch

Record who can change the message, repair retained drafts and investigate repeated failures. Agree when the AI route should be paused and how users will be told. If the task cannot be completed safely through the fallback, say so rather than inventing a reassuring alternative.

Your planning note can be short: failed task; known state; user choices; owner; recovery test. Walk through it with product, design and engineering using a deliberately failed request in a test environment. Check that the manual route works when the AI service is unavailable, rather than only when the demonstration goes smoothly.

Choose one AI-assisted task this week and write its failure message before its success message. You will uncover product decisions that a polished demo can leave unanswered.

Leave a Reply

Your email address will not be published.