Blog Archives

Day Three at DevLearn 2013

The final day of DevLearn had me sitting in sessions led by Clark Quinn, Conrad Gottfredsson and Neil Lasher. Since there were so many overlapping concepts, I’ll just cover them based on the two overriding themes I saw rather than by session.

Start at “apply”

The problem that instructional design seems to face is that requestors bring us in to situations that don’t always require instruction. So instead of creating unnecessary instruction, start design by trying to understand what the end user needs to do to perform a behavior. If the design demands the introduction of new knowledge, introduce that knowledge within the relevant context, then provide the ability to apply that knowledge in practice and offer appropriate feedback. But if performing doesn’t require instruction, don’t force it. As Clark Quinn mentioned earlier in the panel discussion, “build knowledge into the world, not in the head.”

In terms of deciding what needs instruction and what doesn’t, Conrad Gottfredson presented a beautifully simple system for sorting it out. While performing your task analysis, determine the negative consequences your learners face should they fail and rate it on a scale of 1 to 7, 1 being no effect, 7 being catastrophic (I would probably add a level 8, just in case failure leads to a zombie apocalypse). Anything rated 5 or higher gets the most instructional attention, anything rated a 3 or lower gets mostly performance support. It’s so simple, but it’s a brilliant way to make sure our end users get the support and practice they need to perform (and not cause a zombie apocalypse).

I like the emphasis at this conference on building smaller bits of content as performance support instead of courses. I never went to school intending to become a technical writer, but somehow when I landed my current role as one, it seemed to be a pretty natural fit. I think if instructional designers better understood the things technical writers produce (help systems, job aids, documentation) and if technical writers understood the skills that instructional designers can leverage (user centered analysis and design, multimedia instruction) both professions would be in a better place.

I think since my department has a history of delivering on these things, most of our requestors are willing to be talked into performance support solutions, even if their initial inclination is to request training. There are other challenges, of course, namely how do we respond to requesters demanding a small forest’s worth of printed documentation (destined to go out of date almost as soon as the training ends)? And how do we optimize documentation so that it covers everything that needs to be covered while being attractive and not intimidating for the user?

Then there’s problem of managing and tying all of these things together, which leads us to…

Build an ecosystem

When it comes to supporting performance, elearning is just the start. As Art Kohn mentioned on the first day of DevLearn, nothing can be taught in one pass, as the learner will almost immediately forget it. Instead the goal should be to build an ecosystem of learning and support by using all of the tools at our disposal. This means EPSSs, job aids, pocket cards to support performance as well as mobile delivery and context to support instruction. Additionally, managing it requires content governance to ensure the most relevant things are easily discoverable and not lost beneath a mountain of outdated content.

Neil Lasher displayed a brilliant example that tied in some of the transmedia storytelling ideas in Lee Lindsey’s session on day one. He presented a simple scenario of a top sales employee at a retail outlet angrily tossing a customer out. You’re then presented with several options:

  • Verbal Warning
  • Written Warning
  • Suspension
  • Firing

Making the wrong choice (in this example, a written warning) causes the employee to storm out and quit. Later on, you’ll receive an email or SMS offering additional information and coaching. A couple days later you’ll get another SMS, saying there’s a situation developing with another one of your employees. It leads you into another scenario where you have to deal with an employee causing problems because they saw the other employee quit angrily a couple days ago.

It’s a real time scenario. Like Animal Crossing for new managers! 🙂

As more scenarios are developed and new content is required, more pieces to the ecosystem (both instructional and performance support) are added. It’s important to note that at no point is any “score” information provided, as simply receiving feedback from the scenario is enough. Score data is only used on the backend to calculate what the system should send the user to next.

Keynote: Talent Anarchy

Though I found the Talent Anarchy keynote on hacking to be a useful tool that I’ll be implementing on an almost daily basis, I don’t know how much I can add to the conversation around it. Instead, I defer to Bianca Woods and Cammy Bean who have posted excellent recaps from the session.

And that’s it!

I want to thank everyone for another great DevLearn where I learned new things, gained tons of inspiration and met people doing some very exciting work. Rather than being an end, DevLearn last year was a real kicking off point. Many of the things I’m only just putting into practice were inspired by those sessions, and I suspect it’ll be similar this year.

Advertisements