Adoption is a design problem, not a training problem

The tell is the reversion

A team is trained on a new system, uses it for a fortnight, and drifts back to the old way. The usual diagnosis is that they need more training or that people resist change.

Both explanations are comfortable and usually wrong. People are relentlessly efficient about their own time. If they abandon a tool, it is because the tool costs them more than it returns, and they worked that out faster than anyone measuring adoption.

The useful response is not another session. It is to watch the specific task where they gave up.

Count the interactions for the common case

Take the action someone performs forty times a day and count what it costs. Clicks, fields, page loads, decisions. Then count the same thing in whatever they were doing before.

A system that is comprehensive but takes ninety seconds for something that took fifteen will lose, and it should. Completeness is a benefit to whoever designed the schema and a tax on whoever does the work.

Optimising the frequent path at the expense of the rare one is almost always correct, even though it feels wrong in a requirements meeting where every field has an advocate.

Data entry that benefits someone else

A reliable adoption killer is asking one person to enter data purely so another person can have a report. The cost is immediate and personal, the benefit is invisible and belongs to someone else.

Sometimes that is genuinely necessary. When it is, the honest move is to make it as cheap as possible and to close the loop, so the person entering it sees something useful come back. Silence guarantees decay.

Where it is not necessary, cutting the field is the fix. Every field you remove is a field that cannot be filled in wrong.

Ship to one team first

Rolling out to everyone simultaneously means discovering adoption problems at maximum blast radius, after the design is expensive to change.

One team, one workflow, in production surfaces the same problems while fixing them is still cheap. It also produces something more persuasive than any training session: colleagues saying the thing is genuinely faster.

The people who resisted hardest are frequently the best pilot group, because they will tell you precisely what is wrong instead of being polite about it.