The Adoption Problem is a Design Problem

I've been called in to three AI projects in the last six months where the same conversation happened. The team had built something impressive. The model was good. The integration worked. The demo, in a controlled environment, was genuinely magical. And nobody on the actual team — the people whose work the AI was meant to support — was using it.

When I ask why, the leadership team gives me a list: people are change-averse, the team is too busy to learn it, we need more training, we need a stronger mandate from the top. All of those things are sometimes true. None of them is usually the actual reason.

The actual reason, almost always, is that the tool is hard to use.

Here is a fact about the working life of every professional services team I have ever met. The amount of friction they can absorb in a new tool, before they quietly drop it and go back to the old way, is extremely small.

We're talking minutes. Not hours, not days. Minutes.

If the tool requires the user to log in to a separate system, copy a piece of data from one place to another, format a prompt in a specific way, remember which model to use for which task, or wait more than a few seconds for a response, the friction budget is already spent. They'll use it once because you asked them to. They will not use it the second time unless something in the design is genuinely easier than the alternative.

There is a pattern I see again and again, and it is almost always lethal to adoption.

The team builds an AI capability inside a new surface. A chat window. A separate app. A standalone tool. The reasoning is sensible — "we want to give the AI room to breathe, we want it to feel different, we want users to engage with it deliberately". The result is that the AI lives in a place the user has to choose to visit, and the user has many easier ways not to visit it.

Contrast that with deployments that work. The AI is inside the workflow. It is in the place the user already goes. It shows up where the user already has data. It produces output in the form the user already needs. It does not ask the user to come to it. It comes to the user.

Across the deployments I've seen succeed — across real estate, accounting, insurance, construction, professional services — the design patterns rhyme. Here are the five that travel:

One. Embed, don't relocate. Put the AI inside the tool the user already opens twenty times a day. The CRM, the inbox, the document workspace, the spreadsheet. Don't ask them to come to a new place to access the new capability.

Two. Default to action, not chat. Most people don't want to have a conversation. They want a result. "Draft a reply" is a better entry point than "how can I help?". The chat window is a low-discovery surface; users don't know what to type. The button or menu item that takes a single click is a high-discovery surface.

Three. Make the first time succeed. First impression is permanent. If a user's first attempt produces a result that's mediocre, they will not come back. Spend disproportionate effort on the first-use experience. Pre-fill prompts. Use sensible defaults. Show what good looks like before they have to make any choices.

Four. Make the output editable in place. AI output is rarely perfect. If the user has to leave the AI surface to edit it, fix it, or refine it, you've broken the loop. Edits should happen where the output appears, instantly.

Five. Hide the model and the mechanics. Users do not care which model is running, what the system prompt is, or how the retrieval works. They care whether the output is useful. Anything you expose to them about the underlying machinery is a tax on adoption, paid in attention.

There is a particular failure mode worth calling out. When a tool isn't being adopted, the instinct is to throw training at it. More sessions. More documentation. Lunch-and-learns. A power-user champion.

Training does almost nothing to fix bad usability. It does some good, but the curve is brutal. A tool that takes thirty minutes to learn before it pays off has lost the majority of its user base in the first five minutes. No amount of training reaches the users who quit on minute four.

If you find yourself reaching for training as the answer to an adoption problem, ask first whether the tool is hard to use. The answer is almost always yes, and the right fix is upstream of any classroom.

Most of the conversation about AI strategy inside companies treats the AI as the hard part and the deployment as a logistics problem to be solved after. This is backwards. The model is, by the standards of the last decade, the easy part. Getting the model into a form a human will reach for, on a Tuesday morning, when they're tired and behind on email, is the hard part.

Treat usability as a first-class design concern from the beginning of the project, not as a polish step at the end. Pilot with the actual team that will use it, in the actual workflow they will use it inside, and measure adoption — real adoption, repeat use — not training-session attendance.

The AI tools that win the next decade will not be the most powerful. They will be the ones that disappear into the workflow so completely that the user stops thinking of them as "AI" and just thinks of them as how the work gets done now. That's a design problem before it's a model problem, and most teams are still solving them in the wrong order.