Rapid eLearning Development – Rethinking ADDIE

by

I think most eLearning developers are familiar with ADDIE. It stands for Analyze, Design, Develop, Implement, and Evaluate. This is the process we all learned when we started to design learning. The problem is that designing eLearning never seems to work this way.

It is very rarely a smooth and straight path, at least not for me. I find myself analyzing the requirements of a course, and then building pieces, then testing those pieces, and then rebuilding pieces, retesting them, and eventually putting all the successfully tested pieces together. The point is that I find myself building and testing over and over again.

The problem with ADDIE is that Design, Develop and Evaluate happen repeatedly throughout the process, not just as a single phase in the creation process.

Design and development is an iterative and cumulative process. It is also cyclical. Essentially, I find myself following a disciplined process repeatedly – not just following a cycle of chaos.

Maybe we need to rethink this process a little to include the cyclical phases.

How about this? Typically, I only use about four stages.

Analyze…Design…Build…Evaluate…Analyze…Design…Build…Evaluate…and so on.

Essentially, it is analyze the situation, propose a solution, build or prototype that solution, and evaluate the results. Typically, the results are not perfect. So, then, I analyze what went wrong, propose a new solution (usually enhancements to the previous solution), build that in a way that is a little more refined, and evaluate the results. If the solution is still not providing the necessary solution, I start back at the analyze phase and repeat the process. Rarely do I need to do these steps more than three times. I probably missed the mark at the beginning if I need to repeat this too many times, and am better off starting over.

ANALYZE

The first time I analyze, I am discovering the situation for which I am trying to provide a solution. I find out who my learner is and what they need. I analyze the previous solutions and determine why they did not work. I look at previous attempts to make the learning experience better and understand why they failed. I identify what my learners will need to do when they complete my training. Essentially, I am defining my problem and understanding my design options.

DESIGN

This is when I formally identify what my solution needs to be. I identify the components of the solution and define the “whole” as a coherent entity that includes a strategy for delivering that “whole”. For example, I identify that I have five learning objectives. Each of those objectives might get a lesson. One lesson might include a simulation of an interaction with a customer. I also identify what form the assessment will take on. I have requirements for my delivery methods due to an eLearning “shell” we use and how it communicates to our LMS. Therefore, my solution needs to meet these requirements as well. My deliverable, at this phase is typically some kind of document or outline (formality is based on the size of the final deliverable – some projects just need an understandable path to follow, while others require a more complete design document explaining all the pieces and how I plan to assess the learners). This stage might include some storyboard development, as well as prototyping an idea to see how it might come together…and most of all…do I have the capability to develop what I want to develop. I have scrapped many ideas at this phase because I learn that time or lack of personal knowledge will not meet the required timeline.

BUILD

This is the easy and creative stage. I find this stage moves the fastest for me. This is when I create my first attempt at my solution. It usually involves creating some basic media in Photoshop, template ideas in PowerPoint, and eventually recording audio for the script. Many times I build this using the prototype as a starting point.

EVALUATE

Now we find out how close to the target I got. This is the time to improve our design and enhance the first prototype. I find that I usually only need to test with one or two other people, besides myself. To me, the fact that it is not me doing all the testing is critical. I built my solution, so I know what objects to click or what text to enter. I need others to “break” my design and identify the flaws. This is when I get a better handle on where I need to provide better feedback, more variety in correct text entry answers, pauses in my presentation so the learner can read (or the opposite – more instruction because the learner was lost).

SMEs AND STORYBOARDS

There is a key element in working with SME’s that I have seen to be true – they have a hard time “seeing” a final product from a storyboard.

Many times, it isn’t until the Evaluation stage, that they are able to realize some component of the presentation did not work as expected, a scenario wasn’t complete, an example could have come across better, or they did not fully follow the flow of the screens. This happens even after they commit to the storyboard in the design stage.

Missing content is a primary offender in this evaluation. SMEs seem to have a hard time seeing a final product from a storyboard. Many times, the SME assumed that content would be covered or did not realize, based on the storyboard, that they missed informing me of a key piece of content, and therefore I failed to include it. It isn’t until they walk through the course as a whole entity that they realize they did not provide it or I failed to include it. This includes scenarios I create. Sometimes the tone of a scenario or the facts used within a scenario are not presented as the SME expected or how an event occurs in the real world.

This single fact is one of the key reasons I end up back in the analysis stage after the first round of evaluation.

WASH, RINSE, DO NOT REPEAT…EXACTLY

It is not quite a full repeat, really. I do go back to the analysis stage, but this time, I don’t need to perform the same analysis I did when I started the project. This time, I am analyzing what went wrong and what I need to fix the issues that arose. Once I know what I need to do, I rebuild my course. Then, we are back to the evaluation stage again. I repeat this process I until the course passes the evaluation stage.

NOT EXACTLY ADDIE

So, it may look like I left some stages out, if I were to follow ADDIE. I did not. I merely consolidated Develop and Implement into the Build phase. In eLearning, the implementation of your course is a natural part of the development of the course. Since the process is iterative, rather than sequential, these two happen very close together and sometimes repeated several times.

The design process includes testing at every level and involves me being willing to return to the beginning and try new things. At the beginning, I am dealing with high-level issues, like trying to define if I want to attempt to try something new and if I have the skills or toolset to pull it off successfully. This requires that I sometimes need to work with a stripped-down prototype. At this stage I am working with concepts. This prototype could be as simple as a series of drawings or as complex as actually building a sample module or lesson. At the end of the final Build phase, I am dealing with details and tweaking the final deliverable.

What model do you follow? What works for you? Do you find that when developing eLearning, ADDIE seems to miss the mark slightly?

Advertisements

Tags: , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: