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

March 4, 2019

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:

• What is the course going to look like? Where will the title be displayed? What will the navigation buttons look like? What navigation will be necessary?
• How will the learner know how the course will proceed? Will there be a progression model visible to the learner? Will there be a table of contents displaying the course content?
• How much standardization is necessary, while not restricting the creativity of the developers?
• What are the expectations of the sponsor(s)?

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:

• Visual Design and Lesson Format
• Instructional Design and Strategy
• Project Management Methodology

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:

• Title Screen
• Introduction – Like the introduction to a college thesis or an article, this section needs to grab the learner and get them excited for what they’re going to learn.
• Overview – While the introduction tells the learner what they’re going to learn, the overview tells them how they’re going to learn it. This section will tell the learner the duration of the course and explain any unique features they may encounter over the run of the course or module.
• Learning Objectives – This section will review the knowledge or skills the learner should attain by the end of the course or module.
• Course Content – The meat of the lesson will occur here. Keep the learner focused. Keep pages simple and consistent, where possible. If the learner spends too much time adapting to new methodologies within a single lesson, they’ll lose focus on the content.
• Conclusion – Summarize what the learner has just learned. Tie it into the introduction, to help the learner solidify the course as a whole experience.

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:

• What type of navigation will be used? Where will the buttons be positioned in the interface?
• What font should we use? What size should it be? Will you use numbers or bullets for lists?
• How will important words be highlighted? Will the text be a different color? Will it be in boldface or italicized?

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:

• Analysis – During this phase of development, you’ll complete all of your research for the upcoming course or module. Examine your audience. Determine their expertise level when working with technologies. Make note of any constraints you’ll have to work within.
• Design – The majority of this phase of development will leverage the design and format portion of your developer’s guide. Here, you’ll ensure that this course or module will work with those guidelines and make any adjustments necessary.
• Development – In this phase, the course is developed. It’s typical to loop between design and development, as each can force the other to change. Again, this phase will leverage the previous portion of the guide.
• Implementation – This is the phase where the course is delivered, by either being made available to your learners, if you’re an in-house development shop, or sent to the client if you’re a third-party developer.
• Evaluation – Receiving feedback from learners and sponsors or clients will not only help improve this course specifically, but it can also drive changes to the development guide as a whole.

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.