Dave's Whiteboard

Designing learning, or, what would Elmore do?

February 7th, 2012

Okay, I confess.  Elmore Leonard does not have any advice for better training.  Not that I know of.  But a book review I read yesterday reminded me (as if that were necessary) how much I’ve enjoyed his writing.

I also enjoy the list of rules for writing he says he’s picked up along the way. An example:

5. Keep your exclamation points under control.

You are allowed no more than two or three per 100,000 words of prose.

One thing he strives for, he says, is “to remain invisible when I’m writing a book.”  So the rules are “to help me show rather than tell what’s taking place in a story.”

That’s a pretty decent starting point to take if you’re creating something that’s meant to help other people learn.  So I thought I’d see if you could adapt his rules to designing for learning in the workplace.  Or to supporting learning.  Or at least to keeping away from CEUs and the LMS.

1.  Never open with “how to take this course.”

Angry Birds is a software application in which you use launch suicidal birds via an imaginary slingshot to retaliate against green pigs who’ve stolen eggs and are hiding in improbable shelters.  12 million people have purchased Angry Birds in the past two years, none of them because of the “how to play Angry Birds” module.

Honestly, there are only  two groups of people who look for “how to take this course.”   In the first group are those who designed the course, along with the lowest-ranking members of the client team.  In the second group are folks who still have their Hall Monitor badge from junior high.

2.  Never begin with an overview.

I can’t do any better than Elmore Leonard on this one:

[Prologues] can be annoying, especially a prologue following an introduction that comes after a foreword.  But these are ordinarily found in nonfiction. A prologue in a novel is backstory, and you can drop it in anywhere you want.

Cathy Moore worked with Kinection to create the military decision-making scenario, Connect with Haji Kamal. If you haven’t seen it, click the link. It takes about 10 minutes.  And notice: the overview on that first page is 17 words long.

3.  Never use “we” when you mean “you.”

Maybe I was a grunt for too long.  Maybe I’m just contrary.  But anytime I run across some elearning that’s yapping about “now we’re going to see,” I think, “who’s this we?”

“We” is okay when you’re speaking in general about a group to which you and your intended audience both belong.  But especially in virtual mode, it wears out quickly.

4.  Don’t act like you’re the marketing department. Even if you are.

This is a first cousin to the “we” business.  Once at Amtrak, a group of ticket clerks was learning a marketing-oriented approach to questions about our service.  When a customer asks, “What time do you have trains to Chicago?” the proactive response is to fill in the formula, “We have ___ convenient departures at (time), (time), and (time).”

For several stations in my area, there was one train a day in each direction.  From Detroit to Chicago at the time, there were two.

It’s not only bombastic to talk like this, it also confuses a feature with a benefit, a distinction any good salesperson would explain if marketing just asked.  It doesn’t matter if you have sixteen departures a day if I, the customer, don’t find any of them convenient.

5.  Keep your ENTHUSIASM under control!!

I suppose there’s less of this around than there used to be.  I’m a staunch believer in the value of feedback.  I believe just as firmly that feedback needs to be appropriate to the context.  Shouting “That’s great!” for trivial performance mainly makes people feel like they’ve time-traveled back to an ineffective third grade.

6.  Don’t say “obviously.”

The thing about the obvious is: people recognize it.  That’s why so few of us are surprised when we press the button for the fifth floor and the elevator eventually stops there.  Except in a humorous tone (and remember, tragedy’s easy; comedy’s hard), words like “obviously” and “clearly” can sound maddeningly condescending.

7.  Use technobabble sparingly.

When does tech talk become babble?  When it doesn’t pertain to the people you’re talking with. If I’m discussing interface design with people who work in design-related areas, then “affordances” probably makes sense to them.  But, for example, if in a post here on my Whiteboard I say that Finnish has features of both fusional and agglutinative languages, I can think of perhaps one frequent reader who has any idea what that means.  Accurate as those terms might be for linguists, they’re a dead loss for a general audience.

8. Avoid detailed descriptions of things that don’t matter to people doing the work.

This goes with the backstory remarks above, but I’m also thinking of any number of computer-user training sessions I’ve seen. One GE executive told me that the typical Fortune 100 company has more than 50 mainframe-based computer systems, most of which don’t talk well to each other.

What does that have to do with training people to use them?

The typical worker could not possibly care less whether it’s a mainframe, whether it uses Linux, who built it, where it stores data. If he thinks about cloud computing at all (unlikely), he suspects the phrase is mostly puffery, the IT equivalent to “available at fine stores everywhere.”

The introductory course at a federal agency dealing with pensions was stuffed to stupefaction with that sort of data-processing narcissism. What the participants in the course needed to know was: What’s my job, and how do I do it?

The answer is never “the QED Compounder pre-sorts input from the Hefting database in order to facilitate the Rigwelting process.”  Even if these things are technically true (and who could tell?), they’re meaningless.

Not to say that a quick summary of the process is worthless.  It simply has to make sense:

“The Intake Group reviews personnel records from a new pension plan and makes sure they can go into our system so we can analyze them. Once the Intake Group finishes, we cross-check the new account in our system to uncover any conflicts with the data as it appeared in the original system.  The team at the Resolution Desk handles the conflicts that can’t be fixed quickly.”

9. Don’t go into great detail describing the wonderfulness of the business, the product, or the CEO.

As Bear Bryant said once about the motivational codswallop so beloved at alumni dinners, “People love to hear that shit. Winning inspires my boys.”

Certainly you want people to recognize the good qualities–what makes the company and its product valuable to the customer (and thus to the shareholder). Since people in structured organizational learning already work for the outfit, they’ve already got plenty of information, and most likely an opinion, about its world-class, paradigm-shifting splendor.

10. Try to leave out the parts people don’t learn.

What don’t people learn?

They don’t learn what’s trivial (except to get through the unavoidable Jeopardy-style quiz).  They don’t learn what doesn’t relate to their job (or to a job they’d like to have). They don’t learn what they don’t get a chance to practice. They don’t learn what they don’t need to learn because they already know where to look it up when they need to.

And they especially don’t learn what they knew before they got there.

If it sounds like “training,” redo it.

Training, learning, performance — these are all variations on a theme.  I believe if you talk too much about the process of how you train, or how you learn, people nod off quickly. This is especially true of the beloved rituals of the Stand-Up Instructor: icebreakers, going-around-the-room introductions, that creative nine-dot puzzle, and your expectations for this course.

I do think it’s good to find out what people want or hope or expect, but really: if this is a workshop on designing job aids, then assuming I could read the sign at the front, I’m not here for Assumptive-Close Selling for the INFP.