Low AI adoption can be a usability problem, a learning problem or a sign that the tool does not help with the task. Usage figures alone cannot tell you which. Watch someone complete a real piece of work, find where they struggle and test a change that addresses that difficulty before commissioning another course or replacing the tool.
For an internal product owner or adoption lead, the useful distinction is between a person who needs help learning a workable process and a process that remains awkward after they understand it. Both can be true in the same team. The tools and workflows guide covers the broader choice of systems; this article focuses on diagnosing the experience of using one.
Find the difficulty behind the low usage
Ask an employee to show you their most recent attempt. A comment such as “I don't know how to use it” might mean they cannot find the right control, cannot access the required information or do not know how to judge the answer. Each calls for a different response.
Start with the employee's account, including the possibility that their current method works well. In a public Reddit discussion about AI adoption, a Reddit user said they had been offered Copilot but had not seen anything faster or better than what they could do themselves. That is one person's assessment, without a measured comparison. It is still a useful question for an adoption lead to investigate: what would make the proposed task worth doing this way?
Do not turn hesitation into a diagnosis of resistance. Equally, do not infer a broken interface from one unsuccessful attempt. OpenAI Academy's adoption diagnostic distinguishes several possible barriers and asks teams to separate known facts from assumptions. Treat your initial explanation as something to check.
Observe a real task before coaching
Choose an ordinary task with a clear endpoint and permission to use the necessary information. Ask someone who actually does the work to attempt it on their usual device. Include people who have tried and stopped as well as confident users, and account for relevant accessibility needs.
The GOV.UK Service Manual's usability-testing guidance recommends believable tasks, neutral instructions and observation. Explain that you are testing the service and process. The session should not become an assessment of the employee.
For Sam, a neutral task is to prepare an accurate reply and record for a sample group inquiry. “Open the assistant and use the saved prompt” would give away the route you need to observe. Use approved sample details when real guest information is unsuitable for the research setting or tool.
Work through the observation in this order:
- Agree on a useful result. For Sam, the reply and reservation record must agree with the approved availability and capacity information.
- Watch the first attempt. Note where Sam searches, waits, changes applications, repeats information or corrects an output. Ask what Sam expected when something is unclear.
- Record any help you give. If Sam gets stuck, you can help the session continue. Keep the assisted steps separate from what Sam completed independently.
- Ask about ordinary conditions. Was this a typical inquiry? What changes during a busy shift? Does the task happen often enough for the tool to be useful?
- Compare your explanation with Sam's. Describe the observed difficulty and ask whether it matches the usual experience. Keep an alternative explanation beside your preferred one.
Do not read a slower think-aloud session as a reliable productivity benchmark. Speaking, being observed and encountering a sample case can change how people work. Use the session to locate problems; measure ordinary task performance separately when you need a time comparison.
Match the repair to what you observed
Separate the visible event from the explanation. “Sam reopened the availability screen three times” is an observation. “Sam needs training” is an interpretation. Sam might have forgotten a field, been unable to keep two views open or found conflicting information.
Use a short record to take the issue to someone who can resolve it:
| What happened during the task | A possible explanation to check | A focused next step |
|---|---|---|
Sam could not locate the approved assistant | Poor discoverability or missing introduction | Test a clearer entry point and a brief introduction separately |
The assistant could not access approved availability information | Access or integration limitation | Ask the system owner to confirm the supported information path |
Sam could draft a reply but missed a capacity check | Missing task knowledge or unclear review guidance | Practice that check with feedback, then try another inquiry |
Pasting the draft broke the reservation record's formatting | Output and destination do not fit | Test a compatible output format with the system owner |
Sam completed the task but still preferred the existing method | Little net benefit, or an unaddressed concern | Compare accepted results and total effort, then discuss the preference |
These are possibilities, not a scoring system. Save the task, observed difficulty, help provided, proposed repair, responsible owner and the next case you will use to check it. If access is blocked, resolve that prerequisite before judging the employee's ability to use the feature.
Usability includes what happens when AI is wrong. Can Sam correct one detail without recreating the entire reply? Can an unwanted suggestion be dismissed? Can Sam tell what information the tool used? The human-AI interaction guidelines from Amershi and colleagues provide a design lens for these questions, including making assistance available at the right moment and supporting correction. They are design guidance, not proof that a particular change will increase adoption.
If the problem spans several people or systems, use the workflow redesign guide to examine the larger process. A local interface improvement cannot settle who owns a booking exception or which record is authoritative.
Keep training as a testable option
Training belongs in the response when the observed gap is something a person needs to learn: choosing an appropriate task, providing relevant context, checking an answer or recovering from an error. Make the practice specific enough that you can see whether the person can apply it to another case.
Research does not justify declaring either training or workflow design the universal winner. An April 2026 working paper involving 388 Gap Inc. employees examined a structured paired workflow and a different approach to individual AI training. The paired protocol was associated with poorer document results; the training showed a favorable pattern in an exploratory top-score analysis, while its primary continuous quality result was not statistically significant.
The study used different tasks and morning and afternoon conditions. Unequal document completion and length-sensitive AI grading also limit the findings. It does not establish that training beats usability improvements. It does reinforce the need to test the particular intervention under the conditions in which people will work.
For Sam, practice checking capacity if that is the missing skill. If Sam already knows the check but cannot retrieve the approved information, give the access problem to its owner. If both are present, address both and record which change happened when.
Retest the difficulty and the finished work
After the repair, observe another comparable inquiry. A repeated case may look easier because Sam remembers it. Keep the acceptance criteria consistent, and note any change in the task, device, available information or support.
Check three things separately:
- The original difficulty. Can Sam now complete the troublesome step without the same workaround or assistance?
- The finished result. Are the reply and reservation record accurate, complete and usable, with the required human checks intact?
- The next ordinary opportunity. Does Sam choose the workflow again when a suitable inquiry arrives, and what explains that choice?
Fewer clicks are not a sufficient result if a necessary check disappeared. More logins are not a sufficient result if the task takes longer or the output needs more repair. Review effort, quality and the employee's account together.
If the change helped, document the supported route and its remaining limits. If it did not, return to the observation rather than blaming the person for failing to adopt the fix. The next decision may be further practice, a different interface, a narrower use case or keeping the existing method. For follow-up measurement, distinguish activation, retention and abandonment instead of treating all inactivity alike.
Questions about usability and AI adoption
How can we tell whether employees need training or a better tool?
Observe a relevant task before helping, then note exactly what changes after guidance. If the person understands the task but still cannot obtain information, correct the output or complete the handoff, investigate the system or process. If focused practice enables independent completion of a different case, a learning gap may be part of the explanation. One observation is a starting hypothesis, not proof of the cause. Use the task-observation steps to record the distinction.
How many employees should we observe?
Choose participants to cover the roles, devices, accessibility needs and working conditions relevant to the task. There is no universal number that establishes the cause of low AI adoption. Start with a manageable set, compare the difficulties and recruit further participants where important conditions are missing or findings conflict. A small usability study can uncover a problem; it cannot tell you how common that problem is across the company.
Should we put AI inside the application employees already use?
Embedded assistance is worth testing when switching applications or transferring information is an observed difficulty. It may reduce those steps, but placement alone does not establish useful output, appropriate permissions or an acceptable review process. Compare the complete task in both arrangements, including corrections and final recording. Keep the option to decline assistance when it is unsuitable.
What should improve after a usability change?
The specific difficulty should become less disruptive while the accepted result remains accurate and usable. Check whether employees need less help or rework, then follow whether they return at the next relevant task opportunity. Record changes in training and working conditions too, because a before-and-after difference does not by itself show which change caused it. The retest checks separate immediate usability from continued useful use.
