Thanks to Cathy Moore for an excellent LSG webinar on her Action Mapping method.

What really strikes me is that the process is just such damned common sense - albeit very nicely visually articulated. I am asking myself (the webinar is still in progress as I'm writing) why it is necessary to still have this explained to us. But clearly it is necessary when you see most e-learning, overburdened as it is with "stuff" (content). 

There are various reasons why we're overburdened with content, rather than focussing on creating change in people, and these are principally in the areas of SME/client inexperience and inappropriate expectation. Until we overcome these - and Cathy's method is just one tool in our tool-box for this - we'll be stuck where we are. As I've said in various places, clients need educating probably more than learners!

It also occurs to me that this kind of action-focussed approach can only lead towards scenarios/sims/games - or at worst, story-based and case-based "courses". It simply cannot be supported by the current generation of page-based tools and methods...which on the whole is a very good thing. Thanks again Cathy.

I'm seeing a lot of my views about design reflected in the BBC's excellent Design for Life series. And leaving aside the awkward truth that the young designers in the series appear rather weak, this kind of episodic documentary storytelling is something we in the e-learning business should aim to do more of.

For example, I've learned as much about the reality of business decision-making from Dragons Den as I did from my MBA, and my various attempts at property development owe their (admittedly mixed) success to Property Ladder, as to any training I've had or books I've read. Deliberately or not, these TV shows build in many of the "learning functions" and activities that I see so rarely in e-learning, including: paced repetition, goal-setting, emotion, presentation of opposing views, evaluation of options, situation, summaries...and so on. They draw me in and seduce me to be concerned about what's going on, at least for a short while. Above all, they proceed from the specific (the story) to the general (theory), not the other way round. And not an "interaction" in sight. 

Specifically, Design for Life reflects some important facets of design process and thinking that I don't see very often in the e-learning field:

• Design is about getting under the user's skin: in the episode I've linked to, one designer tapes up his eyes and goes for a walk in the middle of Paris so that he can feel what his blind users experience. How often do learning designers even meet their users, let alone try to get a sense of their feelings?
• Design involves bringing who you are to the party; it's about personal expression. It's not an objective, cold science. We know from many design professions that people who express who they are in their work are better designers.
• Design concepts need to be articulated visually. How much text do these designers produce in their presentations? Not much. There are no weighty specification documents, but visual boards and prototypes instead - right from the start.
• Design is about creating experiences, not "content". I've said enough on this elsewhere... 
• Design is a messy, troubled, unpredictable process, not a mechanistic flow of predictable steps.

If we're interested in learning from other design professions (whose members are, on average more highly qualified, better paid and have access to larger budgets than we do), then I suggest Design for Life is a worthwhile piece of CPD.  

I’m increasingly convinced that the roles involved in producing e-learning are changing. This change is being driven by rapid tools, by cost pressure, but also by a widespread sense that e-learning still isn’t really delivering on its now (decade-long) over-promising.

Most e-learning production companies appear to have settled into organizing themselves in ways that resemble 19^th or 20^th century industrial production. Learning (instructional) designers write words, graphic artists do the visuals, technical developers build final products, project managers…er…well in theory they’re supposed to tie it all together, (although I do often wonder what value they would be adding if most of the time if the rest of the team would just take responsibility…but enough of that). Roles are clearly separate and do not overlap, (somewhat like a Subway outlet during busy periods).

The evidence from other design and software industries suggests that this isn’t necessarily the best arrangement. In many cases such an industrial, Taylorian approach leads to miscommunication, disassociation from client and user needs and, somewhat ironically, higher cost. People in such teams are swapped in and out, like cogs in a machine, each seeing only a small part of the process and often never really understanding what they’re contributing to. It’s the kind of teamwork that management writers in the 90s mocked mercilessly (look at anything by Rosabeth Kanter on this).

An alternative approach, and one that’s increasingly being shown to offer clients better value, is to establish smaller, stable teams in which more highly trained people overlap their roles. Overlapping is the critical characteristic. So the learning designer is also an IA (information architecture) expert, who understands graphical interfaces; the graphics person produces a technical working prototype that can evolve into the final product without needing a technical builder; the technical person, if they’re required at all, edits the copy…and so on.  Each transgresses substantially onto the territory of the other. Such teams are more responsive, more capable of delivering what the client needs, and more able to manage themselves.

At the heart of the team is what I’d call an “e-learning producer”, a role that should evolve from our current learning (instructional) designer role. This person designs the learning experience, manages the project and plays a key part in actually building the final product; they have technical build skills. Learning designers are doing this increasingly anyway, using rapid authoring tools. This is going to become more and more productive as such tools increase in sophistication.

There is an increasing number of small e-learning companies, and in-house facilities building themselves around this kind of person, and I’m going to be monitoring their progress carefully. What our e-learning producer now needs is a flexible, sophisticated design and build tool, which I'll write about elsewhere. Neither the current generation of rapid tools, nor higher-end tools such as Flash, are quite right for this role.

I’ve often said that most e-learning design and production processes, as currently practiced, stunt creativity. There are too many people involved, roles don’t overlap enough, there’s a lot of dissociation from clients and learners…it’s all rather 20th Century and industrial.

It seems to me that if there was a tool that allowed a multi-skilled learning designer (ID) to conceive, prototype and largely deliver a final product, this might move us towards a more fluid, creative situation – and potentially a lower cost one.

That’s where rapid authoring tools come in. Using Articulate, or most other rapid tools, I can do the whole lot, from start to finish. The trouble is, these tools are – or have been until recently – too restrictive to generate anything more than the most basic interactive learning experiences. So although I can experiment, try things out with learners and clients and evolve my design as I’m building my final application, I can do so only within the tightest of constraints. 

I got a bit excited when I read what Clive Shepherd said about Adobe Captivate a few months ago. His implication, which I’m picking up from lots of sources now, is that Captivate has moved on from its previous positioning as the rapid systems trainer’s efficiency tool of choice. Apparently I can do some pretty ambitious things in Captivate now, and not just in the area of systems sims.

So a few days ago, when I had a few hours spare, I tried it out. I set out to replicate some of my favourite MCQ structures (“favourite MCQ structures” isn’t a phrase you see often…) in Captivate to see how far I could stretch it in a very short time, without getting drawn into coding, Actionscripting or similar. I wanted to see if I could use workarounds (following Tom Kulman’s lead) to produce more interesting MCQ-type interactions than Captivate has built in.

I also set myself the constraints of having to originate or source all the assets (backgrounds, photos, videos, music, voiceover etc.) in the time I had available, (between just before lunch and picking up my son from the the childminder at 4.30pm) just to see if I could, even loosely call the process “rapid”. You can see the results via the links below. It’s worth pointing out that none of this is optimized (pre-loaders, compression etc.). 

• Video-based MCQ - watch 3 videos then choose which one answers the question.
• Simple scenario - two versions of a basic scenario including alternative feedbacks, consequences etc.; the second one also has rollover resources to help the learner make decisions.
• "Are you sure" MCQ - answer a question; before reading feedback, you're prompted to have a re-think; then you get feedback/consequences

Captivate clearly isn’t my dream tool yet. But I’m happy now that I could produce, in a few hours, with help from a graphic artist, what I’ve often been told could take days, and involve developers, project mangers and so on. 

Getting back to the main point, I’m convinced that using a tool like this, I can offer better value to clients and learners, because I’ll not get tied up in over-complex development processes and lose sight of why I’m doing what I’m doing. I’ll offer more creative solutions because I’m in control of the whole thing, while not being overly constrained, as I am when I use more basic rapid tools. 

A tool like this is – potentially – the basis for very different development processes; processes that can professionalise our industry and offer far better value to clients. NOT because they’re cheaper and quicker, but because they produce better results.

Although these samples are very rough, they taught me some important things:

• All interactions are trackable and scorable, so they could be assembled into a scored scenario, or sequence of scored events. I don’t need to use Captivate’s built in quiz mechanisms, which look a bit crude. So I can build courses, scenarios, games even that have scored and un-scored sequences interchangeably. When I’ve asked this of developers, they’ve tended to suck in their teeth and reach for their code books…
• I can add pretty decent accessibility features very quickly.
• I don’t have to use Actionscript at all, just a few slightly clumsy workarounds. This is important because various sources (including Kineo) have pointed out that Captivate’s Actionscript implementation isn't perfect.
• Now I’ve done these, I could professionalise them in a couple of hours and customize or re-skin them in minutes. That’s rapid enough for me.

This approach – pushing a rapid tool to do things it’s not entirely comfortable with – clearly has its limitations. There are all sorts of things I can’t do: video-driven multi-select MCQs, ratings, decent-looking drag and drops, and so on…But if Adobe could fill in the gaps a bit, improve on the SCORM functionality, and support the product better, I’m sure they’d find a ready market. 

And we could all stop driving poor old e-learners nuts by offering them such dull rubbish. 

PS – having re-read this posting, parts of it read like an advert for Captivate. I promise you it isn’t. I don’t care what tool I use, as long as it does what I need it to do.