Short answer: Many AI adoption problems are not interface problems. They are design-intent problems. When users can see a system is built to replace them rather than make them more valuable, every flaw becomes evidence against it, and the corrections the system needs in order to improve have to come from the people it would replace.
Adoption problems usually get treated as interface problems. Often the user has simply worked out what the system is for, and it isn't them.
An AI system that is right most of the time is asking its users for patience.
Sometimes they extend it. They work around the odd wrong answer, mention the strange ones, and let the thing settle in. Sometimes they don't. Every mistake gets logged, forwarded, and raised in the weekly meeting, and after four months the system is quietly unused.
Same technology, same accuracy, opposite outcomes. It's tempting to look for the difference in the interface.
Why do users accept one AI system and resist another?
Usually because they have worked out what the system was designed to do to their job.
Some AI solutions help a person do more. The work they were already doing gets faster, or wider, or reaches further, and the person is visibly more valuable than they were.
Some are designed to replace one. A replacement design is an AI system whose business case depends on taking over a person's work, rather than making that person more valuable. Not as a side effect — as the point. The business case says so, even if the rollout deck doesn't.
Users work out which long before anyone tells them. They see what the system takes over, they see what's left, and they can do the arithmetic. It rarely needs to be said out loud, and the fact that it is never said out loud is itself information.
Why does every flaw become evidence against a replacement system?
For someone whose job the system might absorb, its failures are not friction. They're an argument.
That changes what a wrong answer means. In the first case it's a bug worth reporting so it gets fixed. In the second it's proof of something the person has been saying since the project started, and there is no reason on earth to help bury it.
None of that is unreasonable behaviour. They are reading the design correctly and acting accordingly. Calling it resistance to change makes it sound like a personality problem, which is convenient and wrong.
Why does a replacement design break the feedback loop?
Because the corrections an AI system needs come from the people it would replace.
Here is where it stops being a soft issue.
An AI system improves through correction. Somebody reviews the output, fixes what's wrong, approves what's right. If the thing is built properly, those judgements feed back. That loop is the difference between a system that gets better and one that stays exactly as good as the day it shipped. It is also, as we argue in Train Later, where the training data for any future model comes from.
The people best placed to supply those corrections are the ones doing the work today. Which, in a replacement design, are the people it would replace.
So the plan quietly depends on someone training their own replacement, carefully and in detail, for months. Occasionally that happens. It is not something to build a delivery schedule on.
What should you ask before designing the interface?
One question belongs ahead of every design decision: who does this make more valuable, and can that person see it?
If the answer is the team, the work is making it visible to them rather than only to whoever signed off the budget. What did you stop doing this week? What can you take on now that you couldn't? Somebody should be able to answer that in the first month, and it should be a better answer than "the system handles some of it now."
If the honest answer is that nobody in the room becomes more valuable, that is a legitimate business decision. Not one this post is going to argue you out of, either. But it should be made with the consequences attached. The feedback loop will be thin, adoption will be slow, and the people whose cooperation the plan assumed have no reason to give it.
Most adoption problems get treated as interface problems, and some genuinely are. It is worth checking the other thing first, because no amount of consistency, tone, or explanation fixes a system whose users have correctly concluded it isn't for them.
A pattern across engagements rather than a single project, and the part of adoption that gets least attention in the design. More on putting AI into real work in the Interactor blog.