Design the Wrong Answer Before You Build the Right One

Useful AI features need a clear path when they get things wrong. Design corrections, fallbacks and uncertainty wording before polishing the ideal result.

An AI feature can look convincing when everything goes well. A document becomes a tidy summary. A customer gets a relevant product recommendation. The screen feels simple because the difficult work appears to be done.

Then the summary leaves out a cancellation clause, or the recommendation suggests an accessory that does not fit. The answer still looks polished. The user has no obvious way to challenge it, correct it or continue without it.

That is not just an accuracy problem. It is a product design problem.

Before polishing the ideal result, design what happens when the result is wrong. A useful AI feature needs an obvious correction route, a visible alternative and wording that does not promise more certainty than the evidence supports.

Start with the mistake that matters

A happy-path design shows the input, the processing state and the successful output. Failure-first design adds another view: the user looking at an answer they should not rely on.

The important distinction is between a minor inconvenience and a consequential mistake.

In a document summary, awkward phrasing may be easy to fix. An invented payment deadline could affect a business decision. In a product recommendation, an unsuitable colour is different from an incompatible replacement part.

Start with the consequences, not a generic warning that “AI can make mistakes.” Identify what the user might do because of the output, and what would happen if it were wrong.

For each serious failure, decide:

• What evidence can the user inspect?
• How can they correct or reject the result?
• What can they do instead?
• Should the product block a related action until someone checks?

These decisions belong in the first product design, not in a help article written after launch.

Give document summaries a correction route

Consider a hypothetical tool that summarizes supplier agreements for an operations team. Its ideal output lists renewal dates, payment terms and cancellation conditions.

Now suppose it says an agreement can be cancelled at any time, but the source contains a notice requirement.

A “Try again” button is not enough. It asks the same system for another answer without explaining what went wrong. A thumbs-down button may collect feedback, but it does not help the user finish their work.

Instead, design the summary so each important claim can be checked against its source. Let the user open the relevant passage without hunting through the whole document. A source reference helps verification, but it is not proof that the summary interpreted the passage correctly.

Make correction specific. In this hypothetical tool, one option would let the user select the cancellation statement, mark it as incorrect and replace it with a verified note. Clearly distinguish that human correction from generated text.

Also decide what happens next. Does the correction apply only to this saved summary? Will regenerating the summary overwrite it? Does another reviewer need to approve it before sharing?

A correction control is only useful if the user understands what it changes.

The fallback should remain visible: “Read original document” or “Send for review.” If a review service is not available, do not imply that someone is standing by. Offer a manual path the product can actually support.

Let recommendations admit missing information

Now consider a hypothetical product feature that recommends replacement filters for equipment.

The customer enters a model name. Several versions have similar names, and the catalogue does not establish which filter fits the customer's version.

A weak design still presents a top recommendation with a prominent purchase button. A disclaimer at the bottom leaves the customer responsible for discovering the mismatch.

A better design changes the result itself:

“Compatibility is not confirmed. Check the model number on your equipment before choosing a filter.”

The next controls should match that message: edit the model number, view compatibility details or browse the catalogue manually. If the business offers product support, show how to contact it and what information to provide.

Allow the customer to reject a recommendation with a useful reason, such as “Wrong equipment model.” Keep their other inputs so they do not have to restart.

Uncertainty wording should describe the missing evidence, not simply sound hesitant. “This might work” gives little guidance. “The catalogue does not list compatibility with your model” explains the limitation and points towards a next step.

Sometimes the appropriate output is no recommendation. Showing no confirmed match is often better than presenting an unsupported choice as confirmed, especially when a mismatch could lead to an unusable purchase.

Make failure behaviour part of acceptance

These interface choices need to become testable product requirements.

For the summary tool, a test could check whether an unreadable section is identified rather than silently omitted. Another could check whether a saved human correction survives regeneration.

For the recommendation feature, test what happens when compatibility data is missing, the customer rejects every suggestion or the catalogue contains conflicting entries.

Check the whole user journey, not just the generated text. A cautious sentence does little good if the main button still encourages an unsupported purchase. A review link is not a fallback if it leads to an unmonitored inbox.

At TEFY, AI product work treats AI functionality as a feature with measurable behaviour, not as a label. The delivery approach includes testing the riskiest assumption before committing budget and evaluating quality against an agreed test set and thresholds.

A concrete example is CardFindr, a TEFY-owned product currently in build. Its design shows unverified merchants as “Unknown” rather than guessing. It is not a published accuracy result. It is a deliberate product decision about what to display when the evidence is insufficient.

Sketch your three worst outputs

Before approving your next AI feature, list the three worst outputs it could plausibly produce. Focus on outputs a user might believe and act on.

For each one, sketch the screen the user sees. Include:

1. The wording that explains the uncertainty or error.
2. The control for correcting or rejecting the output.
3. The route to a person or a manual alternative.
4. Any action that stays unavailable until verification.

Then ask someone who did not design the feature to walk through those screens. Check whether they can recognize the problem and continue safely without instructions.

If you cannot draw a workable recovery path, narrow the feature before building it. To check whether TEFY's services match your needs, you can book a free 20-minute fit call. It is a qualification call, not a strategy workshop, and ends with a clear next step. The immediate task is simpler: make the wrong answer recoverable before making the right answer look finished.