Tuesday, June 12, 2012

My Secret Objective

I've been reviewing what I've done during my relative disappearance from the social media space.

It has dawned on me that all of the "instruction" I have designed in the past few years share one objective:

"The student will know where to find help when he/she needs it."

Hasn't really mattered what the topic has been.
Or what the "stated" objectives are.

That one lone objective has colored the materials I have developed (and what form).

Documentation and online tutorials have been task based and progressively shorter.
Makes it easier for reference.

Larger chunks of instructor-led time (in-person or synchronous on-line) is spent navigating the help systems and reinforcing those behaviors.

I find myself working on more projects where I am designing support systems vs.designing "training"

This is good.

Why do I think that?

- I receive more questions that are follow-ons from existing support materials vs. questions that are IN the support materials.  People actually RTFM!  Never thought I'd see the day.

- The complexity and sophistication of the questions I am asked have increased.  It has been a very long time since I have been asked how to print something.  And that was with an application where they hid the printing function (and it doesn't work very well anyway - don't ask)

- I'm getting more "thank you"s in my in-box.

- Less of my time is spent fielding phone calls, emails and IMs regarding stuff I "trained" and more of my time is being spent on projects.

If I need hard, reportable evidence - I can pull it from my emails, my weekly status report, the help desk system and my time sheet.

When I look at my portfolio over the past year - I don't think I've designed anything that would win ASTD awards.

But something seems to be working.  I'm cool with that.


Dave Ferguson said...

I had a conversation with a longtime friend and former coworker just this week. I wasn't doing well explaining why I'm not interested in grinding out storyboards or creating courses as this colleague understood them.

So I took time to puzzle that out. I didn't get as far as I would have liked, but as you say I'm cool with that -- because you've captured in a single sentence a lot of what I was looking for.

Sometimes, people don't need (traditional) training at all. Especially for procedural tasks, they need support (like job aids, wizards, context-sensitive systems, automation of what's now dopey data entry) they can make use of while carrying out the task.

By "procedural" I mean things that are done pretty much the same way every time you do them. As complex as a lot of business computer systems are, most of the time there's one way, or a couple of ways, to produce a given result in that system.

learning individual tacit skills, and higher skills that combine procedural and tacit knowledge, benefit from guidance rather than support. That can take the form of cognitive strategies ("How can I go about this?") and mental models ("What does this problem area look like?"). There's no one right way to look at these things--something you hint at when you talk about the complexity and sophistication of the questions you receive.

So you're never going to be able to give the answers to all those questions. Ideally, though, you have the lens in boldface: the learner will know where to find help when he / she needs it.

I especially like "help" rather than "the answer." Sometimes they will find the answer, perhaps because the procedural support contained what was necessary to achieve that. And sometimes they'll be able to continue on their own, or in collaboration with others, to reach a solution that fits the situation at hand.

I definitely think there is, if not an award, an illuminating presentation or three in there.

Wendy Wickham said...

Thanks Dave! On my more cynical days - I wonder why I should create "traditional" courses with objectives in the first place.

Or worse - convert courses with objectives that start with "At the end of this course the student will understand......"

It's good to hang with people who understand my pain :)

Great to see you at Innovations in eLearning. Hope to touch base again soon.

Dave Ferguson said...

Someone I talked with at the IEL conference said that he seed training / learning objectives as blueprints for him -- as a designer.

The typical corporate learner isn't even listening during the ISD ritual of reading out Mager-style objectives at the beginning of formal training. Not that the objectives are bad; the reading of them, in that format, is just unnecessary.

What's important, I think, are learning objectives from the learner's point of view. "In this workshop, you'll learn how to set up and manage your own blog. That includes writing your posts, managing comments, backing up your data, and customizing the look."

No, I haven't stated criteria or conditions. I probably need them on my blueprint, so make sure I cover them (either through exercises or through job aids), to the extent the criteria or conditions are important. Maybe what's important is to create some errors for novices to analyze and fix. Or to create checklists that they can use. Or to provide enough about concepts and terms as well as skills that they can make sense of three short "here's how I do it" demos from bloggers like themselves.