We are regularly brought into products where the model is genuinely good and nobody uses it. The team assumes the fix is more accuracy. It almost never is.
In regulated and semi-regulated work, people do not act on a recommendation they cannot defend. If a compliance officer might be asked why a decision was made, and the honest answer is that the software suggested it, the feature will be ignored no matter how often it is right.
Accuracy is necessary. Trust is what gets it used
Trust here is specific and practical. It is the user's ability to answer three questions quickly: where did this come from, how sure is it, and what happens if it is wrong.
A product that answers all three at 85% accuracy will out-adopt one that answers none at 95%. The second is a black box, and black boxes get routed around.
People do not reject AI because it might be wrong. They reject it because they cannot tell when it is wrong.
Show the working, not a percentage
Confidence scores are the standard first attempt and the weakest. Told a suggestion is 82% confident, most users have no idea what to do differently than at 74%. The number feels precise and carries almost no decision value.
What people actually use:
- The specific records the answer was drawn from, one click away.
- How recent the underlying data is, stated plainly.
- What was not considered, which bounds the claim honestly.
- Whether similar past suggestions were accepted or overridden.
That last signal is underused and powerful. Knowing that colleagues accepted this kind of recommendation forty times last month tells a user more about reliability than any internal metric.
Design for correction, not just acceptance
Most AI interfaces optimise the happy path: a good suggestion, an accept button. The interesting design problem is the other path.
When a user disagrees, the product should make disagreeing easy, fast, and consequential. Easy so they do not abandon the feature. Fast so correcting is cheaper than working around it. Consequential so the correction visibly goes somewhere, whether into the model, a review queue, or an audit log.
Products that treat override as a failure state teach users that the software resents being corrected. Products that treat it as a normal, logged, respected action get corrected often, which is how they improve.
The wrong answer deserves as much design as the right one
Every probabilistic feature will be confidently wrong sometimes. What the interface does in that moment sets the ceiling on trust for everything else.
Practically: never present a low-evidence answer with the same visual authority as a well-supported one. Give the system a way to say it does not know, and make that a respectable outcome rather than a hidden error. Make the blast radius of an accepted wrong answer small and reversible.
On one engagement, adding a review step before AI suggestions took effect increased usage. That sounds backwards until you realise the review step was what made people comfortable turning the feature on at all.
Trust compounds slowly and breaks fast
Users extend trust incrementally, feature by feature, and withdraw it wholesale. One bad automated action in a workflow that matters can end adoption of an entire product surface.
Which is why we start these engagements by asking what the worst plausible wrong answer would cost, and design outward from there.
This is the thinking behind our AI product design work. Written by the UXperts team. If this is a problem you are living with, tell us about it.