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

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

Reaching to the stars

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

Chiming in with their thoughts:

  • Julie Dirksen, instructional designer and author of Design for How People Learn
  • Tom Kuhlmann, Articulate guru and renowned development blogger
  • Bill Mills, a 25-year learning leader working at a 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 pioneer of eLearning, advocated at the dawn of eLearning that the “e” should be interpreted to mean “exciting, energetic, enthusiastic, emotional, extended, excellent, and educational” in addition to “electronic.” Sounds promising, but are we 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 that rapid development tools are responsible, in large part, for the existence of the 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 engage learners, capture their minds and energy, and transform them with new skills and knowledge. In contrast, of course, bad eLearning only wastes the organization’s time and money, and it doesn’t produce the desired business results. Learners hate it, and it gives eLearning a bad rep.

So, how did we get here?

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

Many of these solutions were based on PowerPoint as the principle content development tool. Popularity grew quickly due to the promise that 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 first generation of rapid development tools, many RDT companies promised that even SMEs could be a one-person learning development team. No need for an instructional designer, graphic designer, animator, or video or audio producer. One person, armed with subject matter knowledge, a rapid development tool of choice, and, oh yes, a fresh copy of PowerPoint. The eLearning world was spinning. In fact, it still 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 the application and within minutes, and without much instruction, be assembling thoughts and ideas into a presentation.

I hate it for the very same reason.

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

So what’s wrong with this? Plenty. It disengages the audience 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 few resources, and too many demands, eLearning course developers find the rapid development tool set and PowerPoint that often powers it pervasive and very efficient. And, perhaps, even dangerous.

Nothing to show to cover a narrative passage? Reply on a bulleted list. Too much text to squeeze into the allotted space? Allow the program to 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 effectiveness using PowerPoint, in 2004 Cliff Atkinson and Richard E. Mayer produced a report entitled “Five ways to reduce PointPoint overload.” They found that the tools that created ease of development also created ease of cognitive overload. Screens packed with too much text and too many concepts diminished learning outcomes significantly.

Certainly, much has changed in the nearly 10 years that have elapsed 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 all quick to point out that a tool is only that … a tool. Not a solution. All of them said that if not used well, an RDT can become a crutch.

Julie Dirksen

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

Shoving information out the door is not an acceptable definition of training. Yet it is the default state for much of the eLearning content being produced. Development tools bring efficiency to the least important part of the process, and we end up doing only what the software allows us to do, says Julie.

Cathy Moore

Cathy agrees that these tools drive us to creating presentationware. However, she reminds us that people are often very attached to their tools. Often, IDs are told to use specific tools, and clients ask for courses that depend on specific features those tools provide. However, are we simply settling for being a tool monkey and not a designer of training? We must ask questions about the performance goal and business goal for this training before 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 answer to that problem. Often, with proper discovery, we find that training is not the answer. Cathy proposed that a root-cause discovery process will reveal a distinction between what the target audience needs to memorize, what information they need to access, and what they need to do. The solution for all three of these needs will trigger different development paths.

Of course, the question of resource allocation is a crucial one for many training departments. Limited in resources and limited in specialization, training developers look to rapid development tools to meet budget, timeline, and skill requirements.

Bill Mills

Bill observed that eLearning developers are seeking efficiency and expediency; rapid development technology provides that. But he warned 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 rapid development tools provide and, as time permits, build well-designed components that have multiple uses and you can use in multiple courses. Building libraries of commonly used components and repurposing them gains the efficiencies of RDT but also allows you to create high-impact learning objects that you can use multiple times.

Tom Kuhlmann

Tom offered the idea that because of today’s development tools, the process is less involved to get the point of deployment. Not so long ago, we were hand coding; now, getting to deployment is far less time consuming and resource intensive. If the course design is solid, the tools have made it easier to get the course developed and deployed. That’s a significant advantage.

Building mastery

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

  1. A key misstep is to presuppose an answer. Is there 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 setting instructional directions. Think of yourself as a performance consultant rather than one who cranks out volumes of work. And never start the discussion by asking an SME, “What do you want to say on the first slide?”
  3. Know your purpose for the training. Cathy reminds us that there is an important distinction between creating training and developing job aids. While both have a place, that distinction is crucial as to whether the development track is one of eLearning or merely content presentation.
  4. Focus on doing things right. Tom believes that with 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 people tend to build what they are most familiar with. So seek out great eLearning examples, determine what makes them so effective, and replicate them. Knowing the tools in depth allows you to think beyond the obvious solutions and focus on doing things right.
  5. Minimize. Take an existing course and strip out 60 percent or even 70 percent of the content and challenge yourself to see what you can do with what’s left. You will be surprised with the results.
  6. Practice. Build mini pieces and be able to design treatments that can communicate concepts. Use practice builds to sell clients on interactive approaches that you believe could solve their problems. Clients are 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 the basics of visual design. It’s the skill that most frequently goes overlooked in rapid development.
  8. Become part of the learning community. Connect to other users who can help expand your thinking about the tools you use and how 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 even the smallest organizations to develop their own electronic training materials. But just because everyone can more easily build a course does not mean that every course is being built appropriately.

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

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

Are the tools of technology your crutch or jet pack? That answer is in your hands.