Articles / AI & Product

Adding an AI Feature Without Breaking User Trust

Users forgive slow software and ugly software. They do not forgive software that confidently lies to them. Design rules for AI features that keep trust intact.

By Nermeen Zayed · · 2 min read


The first AI feature a product ships usually gets a warm reception. The second one has to earn it, because by then users have seen the model be wrong. How you handle those wrong moments decides whether AI becomes a reason people love your product or a reason they stop trusting it.

Show your work

When a model summarises, classifies, or recommends, let the user see what it based that on. A summary that links back to the paragraphs it drew from is checkable. A summary that appears from nowhere is a leap of faith. The difference in implementation is small. The difference in trust is enormous.

Make the undo obvious

AI features should suggest, not act, until users have had time to see the suggestions are good. Auto-filling a form is fine. Auto-submitting it is not. When the feature does take an action, the undo should be one click and visible for long enough that someone who looks away for a moment can still find it.

Say when you are unsure

Models can estimate their own confidence, and even a rough signal helps. A low-confidence result can be shown differently, held for review, or simply not shown. Users are remarkably tolerant of a feature that says I am not sure about this one. They are far less tolerant of one that is always sure and sometimes wrong.

Keep a human path

Every AI feature needs a way to do the same job without it. Partly because models fail, partly because some users will never want it, and partly because the manual path is how you collect the examples that make the model better. If the only way to categorise a ticket is to accept the model's category, you have no way to learn where it is wrong.

Measure the right thing

The tempting metric is how often the feature is used. The useful metric is how often its output is accepted without edits, and how that changes over time. A feature that is used constantly and corrected constantly is generating work, not saving it. Track the correction rate from day one and treat a rising rate as a bug.

None of this is complicated. It is mostly a matter of remembering that the user, not the model, is the one who has to live with the result.