Everyone learned the AI tool. Almost nobody opened it.

The problem

A mid-sized professional services firm rolled out a generative AI tool to every licensed member of staff. Six months later, fewer than one in five had used it more than twice. That is the one number in this case study I can stand behind completely, because it came straight from the usage logs.

A "how to prompt" session had already run before I got involved. It was not a bad session. Feedback scores were good, the content covered prompt structure properly, and attendance was high because the licence was mandatory. And it moved the usage figure by precisely nothing. People could describe good prompting on a feedback form and still not open the tool on a real piece of work the next morning. That gap, between what people had learned and what they actually did, is where I started.

It would have been easy to read that gap as "the training didn't teach it properly" and book another session. I did not think that was the real story, and the firm's culture gave me a clue why: heavily billable hours, almost no slack to fumble around with a new tool on the clock. A skills gap and a trust gap look identical from the outside. Both show up as low usage. They do not take the same fix, and delivering more prompting instruction into a room that was not short on prompting skill was always going to fail quietly, which is exactly what it did the first time.

The learner and the constraints

The people at the end of this ranged from staff who had never opened the tool to power users who already used it daily and just needed to trust their own output. Everyone was time-poor. Nobody had spare, unbilled hours to go and experiment, and in a culture like that, being seen struggling with a new tool in front of colleagues is not a small thing. It can read as a signal about how competent you are, at exactly the moment your job feels most exposed.

I want to be honest about something here. I never sat down and interviewed this population about how anxious they felt. That was my read of the pattern, capable people, quietly avoiding a tool they knew how to use, set against a culture with no room to be seen getting it wrong. It is an inference, not testimony, and I built the diagnosis to be checked rather than taken on trust.

The approach, and why

I did not write another prompting module. I built a way to test the diagnosis first, because the wrong diagnosis was the actual risk here, not the wrong content.

• Treat the failed session as evidence, not a mistake to write off. It had already moved the skills variable and usage stayed flat. That is not a training failure to shrug at, it is data, and any real diagnosis had to account for it.
• Ask Mager and Pipe's question, plainly. Could they do it if their job depended on it? I checked that against the session's own assessment data and the usage logs, and for most non-users the answer was yes. That routes the problem toward trust, not another skills tier.
• Build the diagnosis as something a reader can check, not a private note. I put the finding on a single matrix: who could demonstrably prompt, against who was actually using the tool live. On the illustrative split I committed to for this exhibit, marked plainly in amber because no real cohort scored it, roughly four in five non-users could prompt fine and about one in five could not. The number is illustrative. The method, checking whether it could have gone the other way, is the actual point.
• Design for two very different people in the room. First-time users needed the basics. Power users needed judgement and verification practice, not another explanation of what a prompt is. One generic session was never going to serve both.
• Put the fix where the trust gap actually lives. A three-tier pathway, self-serve, with line managers reinforcing it in protected, billable-hours-safe time. A manager visibly backing someone to experiment does something a slide deck cannot, it tells them their job is not on the line.
• Assess judgement, not typing speed. The Tier 3 scenario hands learners a real client-facing task and a deliberately flawed AI draft. They have to find the error and correct it against a real workflow standard, which is a different skill entirely from writing a good prompt.
• Measure whether behaviour moved, not whether people enjoyed the session. The evaluation runs on usage-log data and time saved, Kirkpatrick Levels 3 and 4, with satisfaction scores deliberately relegated to a minor input. Satisfaction is exactly the measure that let the first failure hide for six months.

Artefacts

The outcome

The honest number here is the one I started with. Everything the redesign is meant to move is a target until a real cohort runs it.

What I took from it

The people most able to use that tool well were the ones most afraid to be seen using it. So the thing least worth building was more prompting instruction, and the thing most worth building was permission. Awareness was never the gap. Skill was never the gap either, not for most of them. The gap was that nobody had told them, in a way they believed, that it was safe to be seen getting it wrong on the way to getting it right. You do not fix that with a better prompt library. You fix it by checking your diagnosis before you design anything, and by being willing to find out you were wrong.

Further reading: why AI should support, not replace, the designer, the governance behind AI-assisted design.