How do you train users?
No, that’s not an abstract question. How do you train users? There are two basic approaches. In the first, you start by showing the users all the features of the new system and then eventually demonstrate how they can do the specific things they’ll need to get real work done.
The second way is to start by showing users how to do their work with the new system and only later point out the rest of the features that are available somewhere in the software.
Or to put it another way: You can focus on your work, or you can focus on their work. Which approach will work better?
You know the answer. Showing off features is fun for IT people. But hearing about features is mostly useless to users unless it’s in a context. That context doesn’t exist until users have walked through the standard processes they’ll be using this software for. Until they’ve tried it, they can’t really make sense of those features, no matter how great they are.
So why do we keep training users the wrong way? Sure, we’re proud of our work. We like focusing on that. But IT people are also orderly. We like having an agenda for training and covering everything on that agenda.
We know that if we start with a lecture on features — say, by showing users every item on every drop-down menu and explaining what each one does — and enforce a hold-all-questions-until-the-end policy, we’ll stay on schedule. We’ll frog-march users through the feature list, but we’ll fit it all in.
And we’ll waste that first hour or so of the users’ time. After all, they won’t remember any of that stuff. We’ll just end up explaining it again on the help desk — one call at a time.
But what happens if you begin by walking users through a typical transaction — or better still, by letting them walk you through a transaction? Then your orderly agenda rapidly dissolves into chaos. Some users will figure out the system immediately. Others won’t and, because you can’t afford one trainer per user, they’ll do what users do — turn to other users for help.
Meanwhile, a different group of users will start experimenting, looking for ways to use the new system to do the things the old system did.
They’ll get confused. They’ll ask questions you never thought of. Things that aren’t configured quite correctly will quickly surface. Every misunderstanding that you had about the users’ work, and that they had about your instructions, will become apparent.
Sounds like a mess, doesn’t it? But it’s exactly the mess you need. Because that’s your opportunity to answer those questions and clear up those confusions — in a consistent way for all the users.
It’s also your chance to let users design a cheat sheet for the system, right there on the whiteboard with you. From that, users will get the most useful quick-reference documentation possible. And IT will get the real story on what users actually do with the software’s features — what works well, what’s kludgy, what needs fixing fast, what can be left for later.
And you’ll be able to see who the ringleaders are among your users, the experimenters, the ones who fear any change and the ones who just aren’t very quick. Keep track. Take notes. You’ll learn who your best friends and worst problem children will be.
This kind of training won’t be orderly or tidy. You won’t get through your whole agenda. In fact, you’ll likely send those newly trained users out wondering about all those features you didn’t have time to talk about and whether those features will really be useful in doing the work.
In other words, they’ll end up focused on both their work and your work.
And isn’t that the kind of training you wanted anyway?
QuickLink 054458
Hayes, Computerworld’s senior news columnist, has covered IT for more than 20 years. Contact him at [email protected].
