Frooxl

The Evolution of the e-Learning Development Guide: What Is It and Do You Need One?

When you embark on a journey, it’s helpful to know not only where you’re going, but how you’re going to get there. In 1804, Lewis and Clark relied on Sacagawea to guide them through the Midwest. Sir Edmund Hillary may have scaled Mt. Everest in 1953, but only thanks to his Sherpa, Tenzing Norgay.

Even after routes were found and roads laid, we still consulted maps, and later GPS, to make sure we were going the right way. Trying to find your way without some sort of guide doesn’t necessarily guarantee failure, but it certainly raises the likelihood of troubles along the way. Working in the e-Learning industry is no exception.

While it’s not necessary to track down a sherpa to guide you, starting off without any kind of guide can still lead to unnecessary headaches. A common problem in any development house is a lack of consistency in development. What one developer thinks is a good method will come across as amateurish to another. What seems a sophisticated solution will come across as overly-complicated, in the eyes of a different developer.

Even if you eventually come to a spoken agreement ensuring some semblance of consistency, without a guide of some sort, you’re setting yourself up to eventually spend days – if not weeks – of one-on-one time, getting new hires on board with these practices, as opposed to sitting them down with a guide they can reference as they work.

A written guide will ensure that all developers are aware of the standards agreed upon, and new hires will be able to read and refer back to certain topics, once they start putting pen to paper (or hands to keyboard).

How to Begin

Now that you understand why you need a developer’s guide, you’re probably asking yourself how to begin. Asking questions is exactly where you start. Determining the questions that you want the guide to answer will put you on the right path to starting your guide. Some potential questions could be:

Once you’ve identified the questions (don’t answer them yet), you need to define the purpose of the guide. Who is going to use it, and what should they expect to find within its contents?

Commonly developer’s guides cover three distinct sections, which are:

If your guide can encompass these sections, while answering the questions you’ve defined, you’ll have an effective guide that can serve you for quite some time.

Design and Format

The first section to tackle is the most utilitarian of them: the visual design and lesson format. This section of the guide will serve almost as a style guide for a web developer. It will define the look, feel, and interactivity of the courses as a whole.

Start by creating a course structure. This is like an outline for each and every course and module within the course. While the course structure you determine will be uniquely suited to your needs, a common course structure looks like this:

Once you have a course structure, it’s time to refine the guide, to answer specific questions about the format the courses will take. Once again, it’s time to define the questions you want the guide to answer. This time, the questions are specific to the interface (UI) and experience (UX) the users will face:

As fun as it is to play with new technologies and the opportunities they present us with, it’s important to keep things simple. If there are too many bells and whistles in the UI and UX, the learner will no focus on the lesson content. Defining these within your guide will ensure that developers don’t become enamored with new opportunities, without first presenting them to enough people. Remember, the guide can always be modified to include them if they fit the course.

Instructional Design Strategy

Now that the design and format section has covered many of the deep, nitty-gritty aspects of our development guide, it’s time to address some of the higher-level aspects. What design strategy will you use in your development? A common strategy used in e-Learning development is the ADDIE model, which spans:

In the first phase of the ADDIE model, you examine your audience. While this is intended to be specific to this course, there are some aspects of your audience that are unlikely to change. Principles for constructing lessons for this audience should be laid out in this section of the development guide.

This is also a good place to put generalized strategies for high-level module design into play. If you find that adult learners respond better to courses that put them in a familiar scenario – rather than those outside their experiences, for example – note it here.

Project Management Methodology

While the ADDIE model works well for the development strategy, project management doesn’t fit into the same life cycle. For that reason, you should also spell out a project management lifecycle. One example is the waterfall methodology.

Waterfall, perhaps because of the name, is often considered to be a one-way development cycle. Many believe that, once a single phase is completed, you cannot go back. This has lead to a sort of backlash against this methodology. Large projects can take so much time that, by the time they’re completed, the requirements have changed.

Another common methodology is the APM or the Association for Project Management lifecycle. This methodology is broken into four stages: Concept, Definition, Implementation, and Delivery. This methodology allows for iteration between design and development, within the implementation phase. This means there’s an overlap between this methodology and the ADDIE model that could streamline project completion.

Creating a development guide may be intimidating, but the result will be worth the work. And the best part: you don’t have to start from scratch. Find a similar company, and approach their e-Learning department. If they have a developer’s guide, see if you could adopt and adapt it.

The most important thing to remember is that your guide is never truly done. As cliche as it sounds, it is a living document and should change, as new philosophies and technologies are encountered, and as lessons are learned. Just because you’ve used it once doesn’t mean it can’t change. Even though he’d made the climb once with one guide, had Sir Edmund Hillary found out there was an escalator on the other side of Everest, he probably would have moved in a new direction.