≡ Menu

User Training is Like a Joke

Shifts in frame of reference are the root of most humor. We all tell jokes, but we seldom recognize that most jokes are funny because they lead our thinking in one direction and then abruptly cause us to shift our thinking to a different direction. Jokes essentially accomplish mental sleight-of-hand by using the most basic of a magician’s tricks: misdirection. Here’s an example:

A man and a dog go into a bar. The man says to the bartender, “This here is a talking dog. If I can show you that he talks, will you give me a free drink?”The bartender says, “Sure. But this had better be good.”

The man says, “Watch this,” and then asks the dog, , “What do you call the top of a house?” The dog barks an answer, “Roof!”

The man asks the dog, “How does sandpaper feel?” The dog barks out, “Rough!”

The man asks the dog, “Who was the greatest baseball player of all time?” and the dog answers, “Ruth!”

The bartender throws them out of the bar.

The man and dog walk down the street and ponder the exchange with the bartender. Then the dog turns to the man and asks, “DiMaggio?”

This joke raises an initial expectation that the dog will talk, then convinces us that it’s all a hoax. The punch line shifts our thinking abruptly, making us realize that it was just bad questions that caused the problem – not the absence of canine talking ability.

Many jokes within the IT community celebrate system users’ lack of understanding of fundamentals. We talk about the PC user who wants to replace a broken cup-holder (CD ROM drawer) on his computer, or a customer service rep who asks a PC user how many windows he has open and gets the answer, “The windows in my office can’t be opened.” I even saw an absurd example myself back in the days of 5 1/4″ diskettes, when we asked a customer to send us a copy of the data on a diskette and the customer mailed us a paper Xerox copy of the front, back, and insides of the diskette (the customer cut open the diskette to allow it to be copied).

We laugh about these situations, but the training issues are real. System users who are accustomed to working in a certain way will have difficulty when we change the fundamental principles underlying their work. It’s like a joke: first you lead their thinking in one direction (the assumptions of the old system), and then you abruptly alter their thinking by changing the assumptions for the new system without telling them. But with a joke the punch line is funny – our system training just causes heartache for our users.

Last year my family bought a computer for my 84-year-old mother. It seemed to be a logical replacement for her worn-out typewriter, but although my mother has an in-depth understanding of how to use a typewriter (to use the phrase from one of my previous newsletters, “She doesn’t know what she knows.”), the shift to using word processing software on a computer has been very difficult for her. Here are some of the assumption changes that she has confronted so far:

  • Margins don’t have to be set before you begin typing.
  • You don’t have to press the Return key at the end of each line.
  • You don’t have to pay attention to whether the page is full (Soon after she started using the computer, she called me to say that she’d filled her first page; how does she go to the second page?).
  • Since you can edit text after you type it, you don’t have to write a first draft by hand.
  • It’s not necessary to understand every aspect of every setting in the word processing software like you do for a typewriter.

All of these things are obvious to those of us who have used a computer for a while, but these are major hurdles for someone just starting out.

Our Training Approach is Backwards
Think about how most of our training programs will teach someone like my mother to use word processing software. Most of the training will focus on feature/function. The trainers will explain the menus, they will explain the various tool bar options, they will talk about how to perform certain functions like indenting a paragraph. But they will rarely take into account the user’s current frame of reference and specifically list the changes in that frame of reference that will be required of the user in order to use the new system.

Instead, it will be up to the user to read between the lines and figure out the changes in thinking that have occurred between the old system and the new system. Most users won’t do this, and so they will have to resort to rote memorization of a list of arbitrary feature/function descriptions. This is a much more difficult way to learn, and the users won’t be as productive as they could be.

The Way Training Ought to be Done
When you’re training people to use a new system, you should get an understanding of the users’ current frame of reference before the training. Then you can start the training class by explaining to the system users:

  1. The fundamental assumptions that have been made in the use of the old system that will change in the new system,
  2. The specific user limitations of the old system that have been removed in the new system, and
  3. The major fundamental assumptions in the old system that the users can still count on.

Once the expected changes in thinking are out on the table, then you can go on to explain feature/function, tying the feature/function changes back to the list of fundamental assumption changes that you provided at the beginning of the training session (i.e., “we used to do it this way; with our new assumption we’ll do it this other way.”).

The assumption changes are the most important part of the training; they’re the new principles that have to be incorporated into the user’s day-to-day processes. The features and functions are just the specifics on how those principles will be used. Specifics are important, but they’re best presented in the context of how things have changed.

And that reminds me of another joke:

A famous lumberjack in the days of the double-headed axe was asked to be the guinea pig for a revolutionary new technology: the chain-saw. He took the new tool into the woods and tried it out, but initial results were disappointing. On the first day his lumber output dropped in half, and his supervisor attributed that drop to the learning curve with the new device. Gradually the lumberjack improved, but after a few weeks he was still unable to beat his output from his axe-wielding days.
Hearing about the numbers, and seeing a major marketing problem, the chain-saw manufacturer sent his product developer out to visit the lumberjack in the woods.
The developer introduced himself to the lumberjack, and asked to see the chain-saw. The developer looked the chain-saw over, found no obvious defects, and then pulled the cord to start the engine. The lumberjack looked startled and exclaimed, “What’s that sound!”

If only the training for the lumberjack had started with an explanation of the changes in fundamental assumptions….

Comments on this entry are closed.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this. For more information on the use of cookies on this web site, see http://blog.makingitclear.com/cookies/