The Nuremberg Funnel, according to Wikipedia, is a humorous expression for a kind of teaching and learning. It implies knowledge simply flowing effortlessly into your brain as you encounter it–or else a teacher cramming stuff in the mind of a dullard.
(The term dates to at least 15th-century Germany, and I suspect the notion of funneling or otherwise stuffing knowledge into someone is a few months older than that.)
The Nurnberg Funnel is humorous as well, in a slightly drier way. John M. Carroll’s 1990 book, subtitled Designing Minimalist Instruction for Practical Computer Skill, describes efforts to help people learn to use computers and software. In 1981, Carroll and his colleagues analyzed problems that people had learning then-new technology like the IBM Displaywriter and the Apple Lisa.
In one extended experiment, Carroll and his colleagues had volunteers work with the Lisa, its owners guide, and the documentation for LisaProject. The goal was to find out what interested but untrained users actually did with these materials.
Mostly what they did was struggle.
On average, the learners took three times the half hour estimated by Apple and enthusiastic trade journals–just to complete the online tutorial. “Two [learners] who routinely spent more than half of their work time using computers… failed to get to our LisaProject learning task at all.”
Carroll calls into question what he refers to as the systematic or systems approach to user training. To him this means “a fine-grained decomposition of target skills” used to derive an instructional sequence: you practice the simple stuff before you go on to more complex tasks they contribute to.
Carroll believes that “the systems approach to instructional design has nothing in common with general systems theory.” What’s worse is that in the workplace, the highly structured step-by-step approach just doesn’t work.
If only people would cooperate! But they don’t.
The problem is not that people cannot follow simple steps; it is that they do not… People are situated in a world more real to them than a series of steps… People are always already trying things out, thinking things through, trying to relate what they already know to what is going on…
In a word, they are too busy learning to make much use of the instruction.
(that emphasis is Carroll’s, not mine — DF)
After further experiments, Carroll and his colleagues created what they called the Minimal Manual. Earlier they’d made up a deck of large cards “intended to suggest goals and activities” for learners, and useful as quick-reference during self-chosen activity. In chapter 6 of The Nurnberg Funnel, he describes the next stage–a self-instruction manual designed on the same minimalist model.
Training on real tasks
The Minimal Manual used titles like “Typing Something” or “Printing Something on Paper” rather than suboptimal, system-centric ones in the original Displaywriter materials. Carroll’s materials also eliminated material that was not task oriented–like the entire chapter entitled “Using Display Information While Viewing a Document.”
At the same time, the experiment included essential material not well covered in the original document. It was easy for learners to accidentally add blank lines but difficult for them to get rid of them. The Minimal Manual turned this into a goal-focused task that made sense to the learner: “Deleting Blank Lines.” While not catchy, that title’s a big improvement on “how to remove a carrier return control character.”
Getting started fast
In the Minimal Manual the learner switches on the system and begins the hands-on portion of instruction after four pages of introduction. In the systems-style instruction manual, hands-on training begins after 28 pages of instruction.
Learners created their first document only seven pages into the Minimal Manual…. In the commercial manual, the creation of a first document was delayed until page 70.
Carroll shows several ways in which the comprehensive systems-style manual bogs down, overloads the learner, and gets in the way of doing anything that seems like real work. I can remember endless how-to-use-your-computer courses that spent 45 minutes on file structure and hierarchy before the target audience had ever created a document that needed to be saved. This is like studying the house numbering scheme for a city before learning how to get to your new job.
Reasoning and improvising
The Minimal Manual approach included “On Your Own” work projects–for example, make up a document and compose the text yourself. Then try inserting, deleting, and replacing text.
Some explanation is always necessary, but the minimalist approach kept that to… a minimum. “The Displaywriter stores blank lines as carrier return characters.” That’s it. You don’t really have to know what a carrier return character is–what’s important to you as a user is (a) it’s what creates blank lines, and (b) if you delete it, you delete the blank line.
In general, this approach introduced a procedure only once. The three-page chapter “Printing Something on Paper” was the only place that printing was explained. Elsewhere, exercises simply told the learner to print. If he wasn’t sure how, he’d have to go back to that chapter.
In part, the team chose this approach because of the endless and often fruitless searching that learners had done in earlier trials, losing themselves in thickets of manuals and documents. The fewer pages you have and the clearer their titles, the easier it is to find what you’re looking for.
Here’s the entire explanation for the cursor control keys:
Moving the cursor
The four cursor-movement keys have arrows on them (they are located on the right of the keyboard).
Press the ↓ cursor key several times and watch the cursor move down the screen.
The ↑, ←, and → keys work analogously. Try them and see.
If you move the cursor all the way to the bottom of the screen, or all the way to the right, the display “shifts” so that you can see more of your document. By moving the cursor all the way up and to the left, you can bring the document back to where it started.
Connecting the training to the system
Carroll’s subhead here is actually “Coordinating System and Training,” but I wanted to be more direct. His team deliberately used indirect references in order to encourage learners to pay attention to the system they were learning. In those long-ago days, for example, computers had two floppy-disk drives. The Minimal Manual didn’t tell learners which drive to put a diskette in. “We left it to the learner to consult the system prompts.”
Supporting error recognition and recovery
As with other parts of the experiment, Carroll and his colleagues used error information from previous testing to guide the support provided by the Minimal Manual. Multi-key combinations (hold down one key while pressing another) baffled many learners, especially when the labels on the keys were meaningless to them: (“press BKSP, then CODE + CANCL”). And then there was this:
A complication of the Code coordination error is that the recovery for pressing Cancel without holding the Code key is pressing Cancel while holding the Code key.
Good thing we never see anything like that any more, huh?
Exploiting prior knowledge
It’s easy to forget how confusing word processing can be–at least till you try learning some new application for which you have very little background. (I’ve taken a stab at learning JavaScript, and I can see that’s probably not the basis of my next career.) The Minimal Manual strove to counter the relentless, technocratic, system-centric thinking in the original. “The impersonal term ‘the system’ was replaced by the proper name…the Displaywriter.”
I can hear IT people I’ve worked with sniffing “so what?” I’ve actually had a programmer say to me, of a useful but very complicated tool, “If they can’t understand this, they don’t deserve it.”
One particularly useful approach: document names. Back when most white-collar work did not involve computers, people created paper documents all the time, but rarely thought of documents as requiring a name. (What’s the name of a letter? What’s the name of a memo?) So the bland instruction “Name your document” seems like one more small technical obstacle in the way of getting something useful done.
Carroll’s team had learned that naming created lots of problems for learners, and so found a way to ease learning of this unfamiliar concept.
In the terminology of the Displaywriter you will be “creating a document” — that is, typing a brief letter. You will first name the document, as you might make up a name for a baby before it is actually born. Then you will assign the document to a work diskette — this is where the document will be stored by the Displaywriter. And then, finally, you will type the document at the keyboard, and see the text appear on the screen.
It might still feel odd to have to name a document, but the baby analogy brings the idea a bit closer to what the average person already knows.
♦ ♦ ♦
There’s a great deal more in chapter 6 that I’ll have to return to in another post. I wanted to share what’s here, though, because I think it’s extremely relevant to the future of learning at work.
That omnipresent quotation from a movie puppet often exasperates me.
Of course there’s try–in fact, it’s the effort involve in genuinely trying that’s essential. Otherwise, no Jedi training and not much need for a master; Yoda could just take a seat behind Statler and Waldorf.
Trying and succeeding leads to conclusions that may or may not be correct–sometimes they’re simplistic, sometimes they’re downright erroneous. Trying and falling short, in an environment where such trying is encouraged, can lead to analysis, to greater awareness of the available steps, inputs, and tools, and to improved performance.
The bigger lesson, I am more and more convinced, is that comprehensive systems training is a myth. People might spend extended time in formal classes, or labor their way through highly structured text or tutorials, but most of the time they’re looking for how to accomplish something that seems valuable to them. Just tell me how to get these images posted. Let me create a series of blog posts that have automatic navigation. How can I search this mass of data to find things that are X, Y, and Z, but not Q?
As I put it in a different context (vendor-managed inventory), I don’t want to know about standard deviation. I want to know whether the grocery warehouse computer’s going to order more mayonnaise–and how to tell it not to, if that’s what I think is best.
In no way am I saying that analysis doesn’t matter. It matters a lot–witness the skillful observation and analysis of user testing that led Carroll and his associates to the Minimal Manual. That for them was a starting point–they examined data from their testing to gain further insight and to guide decisions about supporting learning.
(I wrote a follow-up to this post:
Minimal Training: a Plunge into the Typing Pool)
Seriously. If technical book authors read and “got” this post, they’d be far more likely to create a bestseller. We tell our authors to put every topic and sub-topic on trial for its life; to make it defend its right to exist and if it can’t build a strong case for why it MUST BE HERE NOW, then it either dies or gets moved to an appendix. From our analysis, approximately half of what is in most technical training documents falls into the “no, you really do NOT need to understand this in order to get s*** done.”
The gap between what we *believe* people MUST KNOW before they can do something and what people *actually* need (or want) to know is massive. This would not be a problem if learners/users were only in it for the intellectual curiosity AND came with unlimited cognitive resources.
Thank-you so so so much for this post.
Kathy:
I like using spreadsheets. One reason I do, I think, is a long-ago article in a computer magazine that taught me how to create macros for Lotus 1-2-3. Nice, goal-focused title (and the subtitle explained what a macro was, for people like me who weren’t sure). Clear examples that easily related to work I might want to do. And focused guidance.
This showed me how to automate any number of repetitive tasks, to the point that I learned to demand this of software.
I certainly didn’t learn to do this from the Lotus 1-2-3 manual, which at times read like the operating guidelines for the Code of Hammurabi.
I’ve said before that many people who like to train, teach, or design instruction have an almost irresistible urge to explain. I know I do. But I also know that teaching is an activity directed at others, while learning occurs within one’s self. The former does not necessarily cause the latter.
Here, here! Because all that matters, really, is knowing how to order more mayonnaise. And I say that in jest, but I mean it in earnest. Software exists to help people DO things. And so any training or documentation needs to help them DO just that.
Cammy, my mayo example comes from a project years ago. Our GE component was working with a partner that had created inventory-forecasting software. This had great potential value for the client, but the forecasting training was dreadful. Half a day (out of two) yammering about various forecasting models (which the computer, not you chose); lots of math-geek blather about standard error and standard deviation.
What this led to was the learner (typically an employee of a vendor, like a condiment company or a cereal manufacturer) thinking “Maybe I should change the forecasting model?” when the whole point of the software was to choose a model based on historical patterns.
The real task for the learner was to look at what the computer’s decisions were and to decide if they were reasonable in light of things like upcoming holidays and the hard-to-project patterns for products that don’t fit patterns well. So, never ever to think “I wonder if the least squares model works?” but rather “Man, that’s not going to be enough mustard for Memorial Day weekend; I’d better order two more pallets.”