Training and Learning: A Different POV

The topic was training users for an upcoming project rollout, and the debate (as always) roamed back and forth between "traditional" (classroom training, scripts & workbooks) versus "experiential", pairing existing users with their counterparts (who are new to the system), walking through the basics (screen navigation, terminology, and step-by-step instructions for the most common required tasks). Training methods are a common area of debate and discussion with system implementation folks, and I can make a great case for any and all sides.

Task Oriented

(This is where I adopt my Pat Buttram voice) I remember back in the day ... we had "green screens", text-based terminals running applications that flowed like the languages they were written in; procedural, top-down, ordered and neat. There was only one path through each process ("This is the way you set up a vendor and cut them a check ... This is the way you set up a lease and charge the rents ... "). The training material was also very orderly - each step of the process was lovingly detailed, keystroke for keystroke. For more aggressively user-friendly documentation / training material, authors included a screen print for every step of the way.

Documentation Lament Part 1 - I typically take issue with folks who insist on a large number of screen prints. Yes, it appears user-friendly, but it's brutally difficult to keep a document like this up-to date and relevant. Even in the green screen days, we saw basic changes to the application that altered the screen's appearance. Since we're providing these images to provide users comfortable reassurance that what they see is what they are supposed to get, each change means a complete reshoot of all the affected screens. More trees die as page inserts and updates are distributed - and electronic distribution is not much simpler, as the document files are quite large, with chunky .BMP inserts that presented a challenge to all of those floppy-enabled sneakernets (back in the day).

High Concept

I remember when my kids were in their early grade school years; I was impressed to learn that some of the first math classes that they took were all about pattern recognition. Brilliant, I thought - that's the best way to learn how to work with the gooey ( graphical user interface , or GUI) applications that were supplanting the chewy ( character-based user interface , or CHUI ) apps from the old days.

As computers became more powerful, programmers built apps to take on event-driven, flexible format tasks that matched the environments they were implemented on. Sure, there were wizards to take you through some basic operations, but when you're typing a document, manipulating artwork, or laying out your spreadsheet, there's no start-to-finish process - you are " creating ". Training for this software is not about step-by-step processes, but complex operations built with common component tasks. The Microsoft Office suite taught us all that there are certain patterns to modern software ( ribbon notwithstanding) - all menu bars were populated with the same basic component tasks. Top left always had File Open / Close, Edit Cut / Paste - and Help can always be found at the rightmost position of your menu bar.

The challenge, of course, is that not all people excel (so to speak) at conceptual learning. Us old folks grew up memorizing multiplication tables, and we've built our careers on a certain facility (based on familiarity) with the step-by-step.

Documentation Lament Part 2 -  The practical document author should see to flexibility and fluidity of GUI applications as a valid reason to forgo the screen prints. There is so much variability to what is presented on the screen - especially when the latest stuff allows you to customize the appearance of menu bars and other options. Alas, the well-meaning training teams still insist on copious screen prints that are even more likely to differ from what the user sees on their screen. Why can't everybody just adopt Microsoft's online help style? The vast majority of it is text based - no screen prints, menu options described with subtly layered in-line constructs like File, Open . Elegant simplicity, and much easier to maintain.

Follow That Guy Around

Of course, the most common training method of all is the modern apprenticeship - follow someone around that knows what they are doing . For companies of all sizes, it still amazes me how many important processes are not documented. Some might claim they are forced into this modus operandi by expedience and/or a slimmed down the workforce; I think it's just human nature. It's hard to get people to effectively document how they do what they do.

Don't get me wrong - I freely admit my preference for this approach, especially when it comes to new programming languages. I can read a technical manual with the best of them, but I do like to have at least one sitdown with an experienced programmer, watching over the shoulder as they take me through the development cycle (edit, compile, debug, run). Just show me on the screen how it works; once I can do my first practical [ hello world() ], I can grab the book, refine my skills, and catch up on the theory.

Good, Bad ... I'm the guy with the gun

Truly, there is no right or wrong answer here. Different people learn things differently; some react better to the spoken word, other prefer the printed, and some folks need to have step-by-step instructions laid out for them. Note that I purposely do not suggest that procedural versus object-oriented learning is a generational thing; I know plenty of old folks that do just fine with the object-oriented, creative, free-form, self-directed style of learning.

The key is that trainer / communicators must be facile in many different methods, and quick to understand which method will work best for your target audience.