The short answer
People adopt software that is faster than their current method for the thing they do most. They resist software that is slower, even when it is better in every other way.
So find the task done fifty times a day and make that one excellent. The rest can be adequate.
Why adoption fails
- Users first saw it at training rather than during the build
- The common task takes more clicks than the old way
- It does not handle the exceptions people deal with daily
- Nobody explained why the change was happening
- The old method still works and is easier
- The people who wanted it are not the people who use it
The last one is the most common in custom builds. A system specified by managers and used by operators will reflect what managers think happens, which is not always what does.
Involve the users who will use it
Not a consultation at the end. The people doing the work know the exceptions, the shortcuts and the reasons the process is not what the manual says.
- Watch the current process being done, rather than being described.
- Ask what the annoying parts are, and fix those first.
- Show working software early and often, even when it is unfinished.
- Let them use it on real work before it is finished.
- Act on at least some of what they say, visibly.
Point five matters more than the rest. Consultation that changes nothing teaches people that their input is decorative, and they stop giving it.
Make the common path fast
| Frequency | Design priority |
|---|---|
| Dozens of times a day | Optimise ruthlessly, keyboard-first |
| Several times a week | Make it obvious and quick |
| Monthly | Make it findable and guided |
| Rarely | Make it possible, guide heavily |
Systems frequently get this backwards, with elaborate support for the monthly report and an eight-click path for the thing done constantly.
Handle the exceptions
Every process has cases the rules do not cover. If the system rejects them, people will find a way around it, usually a spreadsheet, and you will be back where you started with an extra system.
Build a path for exceptions with a record of who approved them. That way the exception is captured rather than hidden.
Do not force it too early
Switching off the old route before the new one is trusted produces resentment and workarounds. Keep it available briefly while the new system proves itself, then close it deliberately with notice.
Watch which tasks people still do the old way. Each one is a gap in the new system, and that list is more useful than any survey.