Designing the override: what users need before they trust an AI suggestion

The prevailing assumption about AI features is that adoption is a quality problem: that once the model is good enough, people will use it. I don't think that's what's happening. Plenty of features with genuinely good suggestions sit unused, and the reason isn't accuracy. It's that the interface gives users no way to judge accuracy in the moment they have to decide.

The correction path is not the edge case. In an AI product, it's the trust mechanism.

Think about the position the user is actually in. A CRM suggests a lead score, or a next action, or which of two contacts is the duplicate. The user has about four seconds and no visibility into how the suggestion was produced. They have three options: accept it and own the consequences, reject it and do the work manually, or ignore the feature entirely. Option three is free, invisible, and carries no risk. Most people take it.

Their reasoning is sound. The cost of a wrong acceptance is asymmetric (a bad merge, a mis-scored deal, a customer contacted with the wrong context), and it lands on them, not the model. Ignoring the feature is rational risk management. Fixing that requires changing what they can see, not what the model outputs.

Three things have to be legible before someone will act on a suggestion.

Where it came from. Not the architecture, the evidence. “Scored 82 because this account opened four emails this week and visited pricing twice” is something a salesperson can evaluate against what they know. “Scored 82” is something they can only accept or reject on faith, and faith runs out fast in a tool people use all day. Provenance doesn't need to be complete or technically rigorous. It needs to be checkable against the user's own knowledge, because that's the only verification available to them in four seconds.

How sure the system is, but not as a number. Confidence percentages are the most over-used and least useful pattern in AI interfaces. “73% confident” is meaningless to anyone who hasn't calibrated against that scale, which is everyone, on their first hundred uses. What works is behavioural: high-confidence suggestions can apply themselves and announce it, medium-confidence ones should ask, low-confidence ones shouldn't appear at all. Let the interface's behaviour carry the confidence signal instead of asking the user to interpret a number they have no reference for. A suggestion that quietly doesn't show up when the system is unsure builds more trust than one that shows up flagged as uncertain.

How to undo it. This is the one that gets designed last and matters most. If overriding a suggestion feels like fighting the product (a buried menu, a confirmation that implies you're making a mistake, a state that snaps back on refresh), users learn not to engage with suggestions at all rather than risk getting stuck with one. The override has to be as visible as the accept, as fast, and free of any implication that the user is doing something wrong.

Some specifics follow from that.

Separate what the AI did from what the user did, permanently. Once a suggestion is accepted it becomes indistinguishable from user-entered data, and that's a problem the first time someone audits the record. Keeping the provenance attached (this field was AI-suggested and accepted on this date, this one was typed) is what makes the feature safe to trust at scale rather than just in the moment.

Design the disagreement as a signal, not a failure. When a user overrides, that's the most valuable event in the system: labelled training data and a UX signal simultaneously. An interface that captures a one-tap reason (wrong contact, outdated, not relevant) turns every rejection into an improvement, and users who see the system change based on their corrections start treating it as a colleague rather than an obstacle.

Never let the AI be the only path. The manual route must stay complete and unpenalised. The moment a feature can only be reached through a suggestion, users who don't trust it are locked out of functionality, and their distrust hardens into a workaround.

Write the microcopy in the conditional. “This looks like a duplicate of an existing contact” invites judgement. “Duplicate detected” asserts a fact the system cannot actually guarantee, and every time it's wrong it costs credibility that carries over to the times it's right. The grammar of a suggestion should match its epistemic status.

The pattern underneath all of it: in a deterministic product you design the happy path and handle errors. In a probabilistic one, the correction path is the product surface where trust is decided. Users don't need the model to be right every time. They need to be able to tell, quickly, when it isn't, and to fix it without friction. Get that right and accuracy becomes a gradual improvement rather than a precondition for adoption.