Getting people to use what we build: training, trust and the first thirty days

A system that is accurate, fast and beautifully designed can still fail, because the people it was built for do not use it. They go back to their spreadsheet, their phone call or their old habits. Nobody is to blame. The system simply never became part of how the work gets done.

This article describes what we have learned about helping people adopt the tools we build, whether it is a monitoring platform, a document assistant or an immersive training experience. Most of it applies to any new system.

Why good systems go unused

• People were not involved, so the tool solves a problem they do not have, or solves it in an unfamiliar way.
• Training was a single demonstration, and nobody remembers the steps a month later.
• The new tool is extra work on top of the old one, with nothing taken away.
• People do not trust the results, and a single early mistake confirmed their doubts.
• Nobody senior uses it or expects others to.
• When something goes wrong, nobody knows who to ask.

Start before launch

Adoption work begins during design. Involve a few real users from the first week, and keep showing them early versions.

• Ask people to describe how they do the work today, and watch them do it.
• Test early prototypes with them, and change the design when they struggle.
• Name a champion in each team: a respected, curious person who tries things first and helps colleagues.
• Agree with managers what will stop being done the old way, so that the tool replaces a task rather than adding one.

Training that works

The best training is short, practical and repeated.

1. 01Role-based: data entry staff, supervisors and administrators need different sessions. Do not train everyone on everything.
2. 02Task-based: teach the five or six things each person does, using their own real examples, not made-up ones.
3. 03Hands-on: people learn by doing, with a guide beside them, not by watching slides.
4. 04Short and repeated: two or three sessions of an hour, spread over weeks, beat one long day.
5. 05Backed by simple material: a one-page guide and a few short recordings that people can return to.
6. 06Refreshed: staff change, and features change, so plan regular top-ups.

Earning trust

People will not rely on a system that they do not trust, and they should not. Trust is built by the design, and by how mistakes are handled.

• Show sources. Let people see where a number or an answer came from, so they can check it.
• Show confidence and limits. Say when the system is unsure or has no answer.
• Keep a person in the loop for important decisions, at least at first.
• Respond to errors quickly and openly. A fast fix after a reported mistake builds more trust than a flawless first week.
• Be honest about what the system cannot do.

Make the first thirty days count

The first month decides the habit. We run an intensive support period after launch.

• Week 1: check in daily with the lead user, watch usage and fix urgent problems the same day.
• Week 2: short calls with each group to hear what is hard, and release one visible improvement based on it.
• Week 3: review the questions that keep coming up, update the guides and run a refresher.
• Week 4: review usage numbers with the sponsor, and agree what changes next.

Measure adoption, not just delivery

• How many people log in each week, out of those who should?
• Which features are used, and which are ignored?
• How long do tasks take now compared with the baseline?
• What do people do outside the system, such as exporting to spreadsheets, and why?
• What do users say when asked what they would miss if it were taken away?

Talk to the people who stopped using it. Their reasons are the most valuable feedback you will get, and they are rarely the reasons that you expect.

The role of leaders

• Use the system themselves, and ask for information from it in meetings.
• Say clearly what the new expectation is, and what no longer needs to be done.
• Give people time to learn. Adoption slows when it is squeezed into busy days.
• Celebrate real improvements, and share stories from the team.

When people resist

Resistance is information. Sometimes it signals a real flaw in the design. Sometimes it comes from fear about jobs or about being measured. Listen, and respond honestly. Make it clear what the system is for, what data is recorded and how it will and will not be used. Where concerns are legitimate, change the system or the process.

A short checklist

• Did real users help to shape the design?
• Is there a champion in every team?
• Is training role-based, hands-on and repeated?
• Does the system show sources and limits?
• Is there a named person to ask, and a fast way to report problems?
• Are we measuring use and talking to people who stopped?

Frequently asked questions

How much should we budget for training and adoption?

Plan for it as a real part of the project, not an afterthought. For many projects, adoption work takes a meaningful share of the effort in the first three months.

What if the team is too busy to learn a new tool?

Make the benefit visible quickly, remove an old task, and schedule short sessions in working time. If the tool does not save time within weeks, revisit the design.

Should we make the tool mandatory?

Sometimes it must be, for example for records. But a tool that is good needs less force. Mandate it only after it works well, and support people through the change.

How do we know it is time to improve or retire a tool?

When usage falls, when people build workarounds or when the task it was built for has changed. Review it at least once a year.

A system is finished not when it is delivered, but when people use it without being asked. Plan for that outcome from the start, and the technology you built will have a chance to make the difference that it was meant to.