Rapid Development Technology: Crutch or Rocket Pack?

Too little time! Too few resources! Too little funding! Toomany demands! The pressures are well known. The solution? Many think it’s rapiddevelopment.

But the question to consider is this: Have rapid developmenttools enabled us to create training that is more effective than ever before, orhave they seduced us down a path that merely produces quantity?

Reaching to the stars

To help me answer this question I reached out to colleaguesand thought leaders to ask them about this question. Are these extremely welldeveloped, extremely capable tools a help or a hindrance? Are they a jet packto new and exciting learning, or a crutch that narrows our options and channelsour thinking?

Chiming in with their thoughts:

• Julie Dirksen, instructional designer and authorof Design for How People Learn
• Tom Kuhlmann, Articulate guru and renowneddevelopment blogger
• Bill Mills, a 25-year learning leader working ata Fortune 200 financial services company
• Cathy Moore, learning spokesperson,instructional designer, and noted blogger

The questions for the stars

There’s a story told that Dr. Bernard Luskin, a pioneerof eLearning, advocated at the dawn of eLearning that the “e” should beinterpreted to mean “exciting, energetic, enthusiastic, emotional, extended,excellent, and educational” in addition to “electronic.” Sounds promising, but arewe really delivering?

We often turn to rapid development tools to save time,refine technique, and improve engagement. These tools are seductively simple,allowing a non-programmer to develop eLearning quickly. In fact, some say thatrapid development tools are responsible, in large part, for the existence ofthe eLearning business as we know it today. But the real question is … is it “good”eLearning?

We all strive for “good” eLearning—those courses that engagelearners, capture their minds and energy, and transform them with new skillsand knowledge. In contrast, of course, bad eLearning only wastes theorganization’s time and money, and it doesn’t produce the desired businessresults. Learners hate it, and it gives eLearning a bad rep.

So, how didwe get here?

Rapid development tools (RDT) emerged … well, rapidly … inthe later 1980s and into the 1990s. These tools allowed someone without aprogramming background to build courses—and the courses could include graphics—andaudio—and video—and animations—and simulations.

Many of these solutions were based on PowerPoint as theprinciple content development tool. Popularity grew quickly due to the promisethat nearly anyone could develop eLearning material. The promise was very appealing:create sophisticated eLearning within the ubiquitous environment of PowerPoint.

Anyone could do it. In fact, with the release of the firstgeneration of rapid development tools, many RDT companies promised that evenSMEs could be a one-person learning development team. No need for an instructionaldesigner, graphic designer, animator, or video or audio producer. One person,armed with subject matter knowledge, a rapid development tool of choice, and, ohyes, a fresh copy of PowerPoint. The eLearning world was spinning. In fact, itstill is.

The problem with PowerPoint

Personally, I have a love/hate relationship with PowerPoint.I love it because it is incredibly easy to use. Anyone can open up theapplication and within minutes, and without much instruction, be assemblingthoughts and ideas into a presentation.

I hate it for the very same reason.

PowerPoint directs users into thinking of eLearning as apresentation deck—a stream of word slides, usually nicely arranged in bullet-pointlists. In fact, the bulleted list is the program’s default state for a newslide. For decades, it has shaped business presentations as we know them.

So what’s wrong with this? Plenty. It disengages theaudience from the instant it appears on the screen. It runs the risk of being stale,tired, trite … and, worst of all, dismissed.

Where developers go wrong with PowerPoint

Responding to the pressures of too little time, too fewresources, and too many demands, eLearning course developers find the rapiddevelopment tool set and PowerPoint that often powers it pervasive and veryefficient. And, perhaps, even dangerous.

Nothing to show to cover a narrative passage? Reply on abulleted list. Too much text to squeeze into the allotted space? Allow the programto shrink the point size. Complicated subject matter? Load up on charts,graphs, diagrams, and a healthy dose of text. Density rules. Overload begins.Clarity departs.

In their investigation into communication effectivenessusing PowerPoint, in 2004 Cliff Atkinson and Richard E. Mayer produced a reportentitled “Five ways to reduce PointPoint overload.” They found that the tools that createdease of development also created ease of cognitive overload. Screens packedwith too much text and too many concepts diminished learning outcomessignificantly.

Certainly, much has changed in the nearly 10 years that haveelapsed since Atkinson and Mayer released their report.

Or has it?

Capable tools? Or critical thinking?

In talking with Julie, Tom, Bill, and Cathy, they were allquick to point out that a tool is only that … a tool. Not a solution. All ofthem said that if not used well, an RDT can become a crutch.

Julie Dirksen

Julie believes current generation tools have made us moreefficient in building “presentationware” rather than courseware. She proposed thatthe crucial part of the problem is how we, as course developers, view our rolein the process. Do we act as presentation experts or performance consultants? Dowe spend the time to understand root causes or conduct a gap analysis thatleads to effective solutions? Or are we simply building better presentationware?

Shoving information out the door is not an acceptabledefinition of training. Yet it is the default state for much of the eLearningcontent being produced. Development tools bring efficiency to the leastimportant part of the process, and we end up doing only what the softwareallows us to do, says Julie.

Cathy Moore

Cathy agrees that these tools drive us to creatingpresentationware. However, she reminds us that people are often very attachedto their tools. Often, IDs are told to use specific tools, and clients ask forcourses that depend on specific features those tools provide. However, are wesimply settling for being a tool monkey and not a designer of training? We mustask questions about the performance goal and business goal for this trainingbefore assuming any tool can solve our problem.

We must also start not by asking what needs to go on slide one,but rather determining the problem and whether training is truly is the answerto that problem. Often, with proper discovery, we find that training is not theanswer. Cathy proposed that a root-cause discovery process will reveal adistinction between what the target audience needs to memorize, whatinformation they need to access, and what they need to do. The solution for allthree of these needs will trigger different development paths.

Of course, the question of resource allocation is a crucialone for many training departments. Limited in resources and limited inspecialization, training developers look to rapid development tools to meetbudget, timeline, and skill requirements.

Bill Mills

Bill observed that eLearning developers are seekingefficiency and expediency; rapid development technology provides that. But hewarned that the answer is not found in the tool, but in the thinking behind it.He challenges his developers to capitalize on the efficiency that rapiddevelopment tools provide and, as time permits, build well-designed componentsthat have multiple uses and you can use in multiple courses. Building librariesof commonly used components and repurposing them gains the efficiencies of RDTbut also allows you to create high-impact learning objects that you can usemultiple times.

Tom Kuhlmann

Tom offered the idea that because of today’s developmenttools, the process is less involved to get the point of deployment. Not so longago, we were hand coding; now, getting to deployment is far less time consumingand resource intensive. If the course design is solid, the tools have made iteasier to get the course developed and deployed. That’s a significantadvantage.

Buildingmastery

But the question remains, has technology made us, astraining professionals, more effective? In trying to ensure that your applicationof rapid development tools and, ultimately, the effectiveness of your courseoutput is strong, a few overriding strategies stand out.

1. A key misstep is to presuppose an answer. Isthere a clear understanding of how the problem can be solved by training?Addressing performance gaps is foundational to an engaging solution.
2. Ask better questions before settinginstructional directions. Think of yourself as a performance consultant ratherthan one who cranks out volumes of work. And never start the discussion byasking an SME, “What do you want to say on the first slide?”
3. Know your purpose for the training. Cathyreminds us that there is an important distinction between creating training anddeveloping job aids. While both have a place, that distinction is crucial as towhether the development track is one of eLearning or merely contentpresentation.
4. Focus on doing things right. Tom believes thatwith rapid development tools, developers can focus on the way to do it right.But to do so means you need to become a true practitioner. Tom says that peopletend to build what they are most familiar with. So seek out great eLearningexamples, determine what makes them so effective, and replicate them. Knowingthe tools in depth allows you to think beyond the obvious solutions and focuson doing things right.
5. Minimize. Take an existing course and strip out60 percent or even 70 percent of the content and challenge yourself to see whatyou can do with what’s left. You will be surprised with the results.
6. Practice. Build mini pieces and be able todesign treatments that can communicate concepts. Use practice builds to sellclients on interactive approaches that you believe could solve their problems. Clientsare far more likely to buy your approach if they can see a sample in action.Build your practice models with this in mind.
7. Boost your graphic design skills. Understand thebasics of visual design. It’s the skill that most frequently goes overlooked inrapid development.
8. Become part of the learning community. Connectto other users who can help expand your thinking about the tools you use andhow you can apply them in ways not initially intended for them.

What does the “e” really stand for?

Development technology has opened the doors to enable eventhe smallest organizations to develop their own electronic training materials. Butjust because everyone can more easily build a course does not mean that everycourse is being built appropriately.

With the development tools becoming so democratized, thedifference between effective, engaging eLearning and those efforts that are notbecomes more clearly drawn and easier to remedy.

In the end, the words of Bernard Luskin come tomind. We should interpret the “e” to mean “exciting, energetic, enthusiastic,emotional, extended, excellent, and educational.” And ultimately … effective!