Designing for Uncertain Outputs

Ordinary features behave the same way every time: tap Save and it saves. Pantry Pal's suggestion button does not. The same pantry can produce different dinners, some ideas will be odd, and now and then the model will be slow or fail. If the prototype shows only the happy path, users meet the unhappy ones for the first time after launch.

The rule

Design the screen for when the AI is wrong, slow or empty.

Every AI feature needs a design for four moments:

• Wrong — the answer is poor or mistaken. Show what the AI used ("Using: eggs, spinach, rice"), let users change the input, try again or tell you it missed. Word results as suggestions, not facts.
• Slow — the answer takes seconds. Show that work is happening and, where you can, show partial results as they arrive.
• Empty or failed — nothing usable comes back, or the call fails. Say so plainly and offer a way forward: a retry, or something useful to do instead.
• Must never happen — some mistakes are unacceptable, like an allergen in a suggested dish. These are blocked by code before anything reaches the screen, never left for the user to spot.

Good design also keeps trust calibrated: people should rely on the AI where it is good and double-check it where it is not. Overconfident wording such as "The perfect dinner for you!" teaches them to stop checking.

The shortcut

Walk the four doors. For every AI screen, sketch four versions: wrong, slow, empty, and never. If you cannot sketch one of them, the design is missing a piece.

These screens belong in the prototype, not after launch. Show testers the failure screens too, and watch whether the way out makes sense to them.

Drills

Answer fast — trust the rule.

Remember

• Design the screen for when the AI is wrong, slow or empty, and block the never-cases in code.
• Walk the four doors for every AI screen: wrong, slow, empty, never.
• Trap: prototyping only the happy path, and wording guesses as facts.