Product Design & UX · Chapter 2 of 5
Designing for systems that are sometimes wrong
Named in 93% of postings. The genuinely new design problem, and almost nobody's portfolio shows it.
Conventional interface design assumes determinism: the button does the thing. An AI feature produces a plausible answer that is sometimes wrong, not reproducibly, and the design has to carry that.
The five decisions that define an AI interface
- Disclosure. Does the user know they are interacting with a system? In many jurisdictions this is now a legal requirement, not a preference.
- Confidence. Do you show it? Numeric confidence is usually meaningless to users and often miscalibrated; hedged language and visible sources generally work better.
- Correction. How does someone fix a wrong answer, and does the system learn from it? A feature with no correction path teaches users to abandon it after the first error.
- The escape hatch. An obvious route to a human or to a manual path. Its usage rate is one of the best quality signals a team has.
- Failure presentation. A confidently wrong answer is far more damaging than a visible refusal. Designing the ‘I am not sure’ state well is most of the safety work.
The portfolio piece to build
Take any AI feature — a summariser, a search, an assistant — and design its wrong states. What it looks like when it is unsure, when it is wrong and the user notices, when it is wrong and they do not, and how they correct it.
Almost every AI portfolio piece currently shows the happy path. Showing the failure design is a genuine differentiator and it demonstrates the judgement the 93% figure is really asking for.
Designing for a system that is confidently wrong
Designing an AI feature is mostly designing for a specific and unusual property: the output is plausible whether or not it is correct, so the interface has to carry the uncertainty that the content does not.
- Make the output editable, not final. A draft the user shapes is a far better shape than an answer they must accept or reject — it converts a correctness problem into a starting point, and it is the single most reliable pattern in this space.
- Show the source when there is one. Not for transparency as a virtue — because a user who can check in one click will check, and one who cannot will either trust everything or nothing.
- Make the cost of a wrong answer visible in the interface. A suggestion that can be dismissed in one tap needs almost no ceremony. A suggestion that sends an email needs a confirmation that names what will happen.
- Do not fake confidence, and do not fake humility either. Both are dishonest when the underlying system has no calibrated sense of its own reliability. Where you have a genuine signal — retrieval found nothing, the query was ambiguous — surface that. Where you do not, do not manufacture one with hedging language.
- Design the failure state first. What does the user see when the model returns nothing useful, or is slow, or is unavailable? That is a large fraction of real sessions and it is almost always designed last, if at all.
The two patterns that consistently work, and the one that does not
Works: the model drafts, the human directs. The output is a starting point in an editable surface, and the user's effort goes into shaping rather than into verification. Almost every durable AI feature has this shape.
Works: the model narrows, the human chooses. Instead of one answer, several options with what distinguishes them. This is honest about uncertainty by construction and it is dramatically easier for a user to evaluate than a single confident claim.
Does not work: the model decides and the human approves. This is the shape most products reach for and it fails predictably. A reviewer facing a queue of confident, plausible-looking suggestions under time pressure approves nearly all of them — and the override rate near zero looks like a well-performing model when it is a non-operating control.
The design test: “what would make a user disagree with this, and is disagreeing as easy as agreeing?” If approving is one tap and disagreeing requires leaving the flow, you have built rubber-stamping into the interface and no amount of training will fix it.
And measure the override rate, because it is the cheapest available evidence about whether the human in your loop is really there.
Check yourself