Loading lesson…
Applied AI / Choosing & Designing
Designing around failure, not the happy path.
Reviewed by Yuvaraj
Most AI feature designs are built around the demo: the moment the model gives a perfect answer and everyone in the room nods. That is the easy 5 percent. AI features do not fail like normal software, they fail confidently, slowly, and differently every time, so the real design work is deciding what happens when the model is wrong, slow, or unpredictable. Design around failure, and the happy path takes care of itself.
A traditional function either returns the right answer or throws an error you can catch. A model has a third mode that ordinary code does not: it returns something that looks right and is wrong, with no exception, no stack trace, and full confidence. Plan for three failure shapes that classic software rarely has all at once:
| Failure mode | What it looks like | What the user experiences |
|---|---|---|
| Confidently wrong | Fluent, well-formatted, factually false output | Trusts it, this is the dangerous one |
| Latency spike | A response that usually takes 2s takes 30s | Thinks the app froze; abandons the task |
| Run-to-run variation | Same input, different output each call | Loses trust; cannot reproduce or rely on it |
Ordinary error handling assumes failures announce themselves. Here the worst failure is silent, so you cannot just wrap the call in a try/catch and move on. You have to design the interface to contain the failure.
Make this real. Say we are adding a feature to a support tool: it reads an incoming customer email and drafts a reply the agent can send. We will design it around what happens when it goes wrong.
The happy path is one sentence: read the email, draft a good reply, agent sends it. Everything interesting is in the other cases, a draft that misstates the refund policy, a model that stalls for 20 seconds during a traffic spike, a draft that quietly promises something the company does not offer.
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
Users calibrate their trust from the framing you give them. Call it a draft or a suggestion, never "the answer." Put the model's role in plain sight, a short line like "AI-generated draft, please review before sending" does more for safety than any disclaimer buried in settings. The goal is for the user to arrive at the output already in a reviewing posture, not a trusting one.
Match the interface to the confidence
The stronger the visual commitment your UI makes to an output, the more the user trusts it. A polished, pre-filled, ready-to-send message reads as "correct." An editable draft in a clearly-labeled draft box reads as "check me." Design the presentation to match how reliable the output actually is, not how impressive you want the demo to look.
When the feature makes a claim, show where it came from. Our reply assistant should cite the specific help-center article or policy it used to state the refund window, ideally as a link the agent can click. Sources do three things at once: they let the user verify quickly, they make wrong answers visibly wrong (the cited article says 14 days, the draft says 30), and they shift the feature from "trust me" to "here is my evidence." A citation the user can check in two seconds is worth more than a paragraph of confident prose they cannot.
Decide in advance what happens for each failure, and make the fallback a first-class path rather than an afterthought.
Any action the model triggers that spends money, sends a message, deletes data, or is otherwise hard to undo must pass through explicit human confirmation. In our example, the model drafts the reply, but a human presses send. That single boundary, the model proposes, the person disposes, turns "confidently wrong" from an incident into a caught typo. Reserve full automation for actions that are cheap, reversible, and low-stakes; put a confirmation step in front of everything else.
A feature that cannot improve is a feature that slowly rots as the world changes. Instrument it so every interaction teaches you something:
Common mistakes