Karl Kapp has an interesting post on teaching software to others.
The one key being drilled into me by my end-users: Context.
Real-world examples of how they are actually going to USE this thing.
Most of the folks I teach are looking for the fastest way to accomplish a particular task. That gets lost in most software training because we get so focused on buttons and features.
- Buttons and features don't require us to actually get out there and TALK to people.
- Buttons and features don't require us to address the messy human portion of the whole exercise.
- Buttons and features are tangible and quantitative.
The type of evaluation I (still!) see in this type of training: A, B, C, or D - which button do you push to print a document?
How often do you push a button in isolation from other processes?
Just blogging I have to find the site by clicking a series of links and images, push a series of physical buttons (I call this typing) to put words on the screen, then click the Publish Post image to start background processes that will place this idea from the editing screen to the blog page and RSS feed where you all can see it.
Never mind the messy process of coming up with the idea in the first place, generating a coherent thought, and remembering basic American English grammar conventions and spelling.
And I haven't even included other people in this process yet (thanks for the idea, Karl!).....
Besides - folks working outside of technology don't look at software as a thing in and of itself. They are looking at it as a tool that will (hopefully) get something useful done with minimal aggravation. If the tool improves HOW that thing gets done, so much the better.
So a large chunk of my face-to-face training still consists of asking questions. In your experience, what types of things did you do and how did you do them? What have you seen so far observing your colleagues? Here's how you do that same thing using this tool (the software).
It's the conversation that makes the face-to-face interaction valuable.