Why AI Adoption Is a UX Problem Before It's a Model Problem

There is a pattern that repeats across AI products in different industries and at different stages of maturity. The model performs well. The evals are strong. The demo lands. And then, quietly, people stop using the feature. They copy the output into a document to check it by hand. They keep the old workflow open in another tab. Or they never open the AI panel at all.

The usual response is to improve the model: more fine-tuning, better prompts, a larger context window. None of that is wrong, but it often treats the wrong constraint. Once a model is good enough for the job, the bottleneck moves. It moves into the interaction layer, where people decide whether to rely on the output, and into the workflow, where the output either fits the decision someone is already making or creates new work.

The evidence suggests this is the common case, not the exception. In BCG's October 2024 survey of 1,000 senior executives across 59 countries, 74% of companies had yet to show tangible value from AI. Only 26% had moved beyond proofs of concept to real gains. The leaders shared a resource pattern BCG summarizes as 10-20-70: about 10% of effort on algorithms, 20% on technology and data, and 70% on people and processes.

The team optimizes the model. The user evaluates the experience. Adoption is decided in the gap between the two.

One visible mistake costs more than you think

Behavioral research has a name for one of the strongest forces working against AI features: algorithm aversion. In a series of experiments, Dietvorst, Simmons, and Massey (2015) found that people who watched an algorithm make errors became less likely to choose it, even when it clearly outperformed a human forecaster. People forgave the same errors from a human.

For product teams, this changes the design question. A model that is right 92% of the time can still lose its users on the first visible miss if the product gives them no way to understand what happened or recover. The 8% is not just an accuracy number. It is a set of moments the interface has to handle.

Too much trust is also a failure

The opposite failure is just as real. Parasuraman and Manzey (2010) reviewed decades of research on automation complacency and automation bias: people monitor less carefully when a system usually works, and they act on incorrect advice from decision aids. Their review found that both novices and experts are susceptible, and that training and instructions do not reliably prevent it.

That is why the right goal is not "more trust." It is what Lee and See (2004) call appropriate reliance: trust that matches what the system can actually do in a given situation. A product that pushes people to accept every suggestion is setting up the failure that later destroys trust entirely.

Microsoft Research's Guidelines for Human-AI Interaction (Amershi et al., CHI 2019) organize 18 validated guidelines around when they apply: initially, during interaction, when the system is wrong, and over time. That structure is a useful audit frame for any AI feature.

1. First contact: set honest expectations

The first session teaches people what the AI is for and how much to rely on it. Most products over-promise here, with a blank prompt box and a cheerful "Ask me anything." That is an invitation to test the system on tasks it was never built for. Better first contact shows what the system does well, what it does not do, and one or two concrete starting points tied to real work.

2. Everyday use: make reasoning inspectable

People rely on outputs they can check quickly. That means showing sources or citations, the inputs the system used, and the specific part of the answer that matters for the decision. Inspectability does not mean dumping the model's internals on screen. It means giving a busy person the shortest path to "yes, this is right" or "no, it isn't."

3. When the AI is wrong: design the recovery

This is where most products are thinnest and where algorithm aversion does its damage. Every AI feature needs an answer to four questions. Can the user tell when the output is uncertain? Can they correct it without starting over? Does the correction teach the system or at least persist? Is there a clear path back to the manual workflow? A graceful recovery can turn a mistake into a moment that builds trust.

4. Over time: change carefully and visibly

Models get updated. Behavior shifts. If people learned to rely on the system in one way and it quietly starts behaving differently, calibrated trust breaks. Products should communicate meaningful changes, keep important behavior stable, and let people adjust how proactive the AI is.

The People + AI Guidebook from Google's PAIR team makes a related point: decide early whether the AI should automate a task or augment a person doing it. That single decision shapes the interface. Automation needs strong monitoring, clear exceptions, and easy override. Augmentation needs the suggestion to appear exactly where the decision happens, in a form that is fast to accept, edit, or ignore.

In practice, the highest-leverage interface patterns are usually modest:

• Confidence that changes behavior. A confidence score that never changes what the interface does is decoration. Low confidence should change the presentation, for example by showing alternatives or asking for confirmation.
• Sources next to claims. Citations attached to the specific sentence they support, not collected in a footer nobody opens.
• Edit, not regenerate. Letting people correct one part of an output keeps their work. Forcing a full regeneration throws it away.
• Human-in-the-loop gates where stakes are high. Approval steps for consequential actions, with the reasoning visible at the moment of approval.
• A visible way out. A clear path to complete the task manually signals that the product respects the person's judgment.

If the only dashboards track model quality, the organization will keep optimizing model quality. Add interaction metrics that show whether the experience is working:

• Acceptance rate by task and confidence band. High acceptance on low-confidence outputs is a warning sign of over-reliance, not a success.
• Edit distance. How much people change outputs before using them shows where the AI is close and where it is not.
• Return usage after an error. Do people come back after the AI is wrong? This is the most direct measure of trust recovery.
• Workflow completion time. If the AI is fast but verification is slow, the total task may not be faster at all.

1. Can a new user say, after one session, what the AI is good at and where it should not be used?
2. For a typical output, how many seconds does it take to verify it?
3. What happens on screen when the system is uncertain? Is it different from when it is confident?
4. When the output is wrong, can the user fix it without losing their work?
5. Is there a stable, visible path to complete the task without the AI?
6. Do you track acceptance, edits, and return usage after errors, alongside model metrics?

Model capability is the price of entry. It is not the product. The organizations seeing real value from AI are, by BCG's account, the ones investing most heavily in people and processes, and in the product, that means the interaction layer. Designing for calibrated trust, inspectable reasoning, and graceful recovery is not polish added after the model work is done. It is the work that decides whether the model is used at all.