Rapid eLearning development in the real world

Photo of man in suit running with laptopGuest post by Kyle Young

“I’ve never been a fan of the whole “rapid eLearning” movement because I just feel that the minute you start speeding up this process you lose something in the value of what you are doing.”

Karen’s recent quote got me wondering if this view might be a shared view amongst the eLearning field.

You see, I’ve had good and not so good experiences with Rapid Development, both as an instructional designer and as a client. But overall I feel there are benefits to adoption.

For the last 3 years, I’ve had the opportunity to work with Kim Gillham at Visumation who introduced me to the rapid approach. Together we worked on refining this model for eLearning at Arrow Energy.

Here’s what I’ve learned from this experience.

Differences in a nutshell

To illustrate a simple picture of the two approaches as I saw it – Traditional, being the one I was familiar with and the suggested Rapid Development, let me start with this table.

Phase Traditional Rapid Development
Analyse Review of content, scope and business objectives

Detailed design document


Review of content, scope and business objectives

Proposal and high level design

Design Conduct design workshop

Define objectives

Develop high level design

Build storyboard

Review and sign storyboard

Conduct design workshop

Define objectives

Develop high level design

Sign off high level design

Build Develop content from storyboard Develop content from high level design
Review 3 x review rounds 3 x review rounds

Alpha round more time provided

Deploy Test and deploy on LMS Test and deploy on LMS
Evaluate Post project Review

Evaluation Plan

Post project Review

Evaluation Plan

You’ll see the basic differences with the Rapid Development approach are:

1. No storyboarding or detailed design document,
2. Interactions are re-used and,
3. The instructional designer is also the developer who builds straight into the authoring tool.

Feels like ground hog day

The Rapid Development approach thus appealed to me.

It simply made sense to reduce time on documentation and provide the client something tangible sooner rather than later.

I also considered the pain points I’ve experienced over and over on previous projects like:

Clients (SME’s and stakeholders) struggle with storyboards.
Historically, storyboards were created for the developer detailing text, content, interactivity and media for each page. We asked SME’s and stakeholders to review and sign off to move to the Build but they often struggle to understand the document and what the actual content will look like. The best you can expect is the text to be signed off.

Storyboards take a long time to develop and review.
Then you still need to build the course! It can take months to get the storyboard signed off. And having it signed off doesn’t ensure big changes once you build it. Storyboarding can also impact the organic nature of design by being prescriptive – wherein developers can add valuable input to design.

Clients often fail to visualise the final product until they see it.
Yes you can develop prototypes or wireframes and show examples of types of interactivity but until they see it, touch it (via the mouse), and experience the flow of their content on screen, they generally don’t have a clear idea of the outcome.

eLearning is more time consuming than people think.
Clients are commonly surprised at how much time and effort they need to allot for design and development. Developing eLearning is normally just one part of their job and unless there is a critical deadline to be met, or they are truly motivated to get it done, they can linger longer on review times and delivery to the project schedule.

This is by no means an exhaustive list and I know you may be familiar with some of these.

What it does suggest is – there are better ways to support the client through the process, keep project deliverables on track, and make the most of everyone’s time.

So with these in mind, the fact that we had two courses to develop in a short time, and a drop dead date of 600 people moving into a building in about 6 weeks, I launched into Rapid Development.

Benefits sell

The outcome?

The courses were developed on time, the approach worked well, especially for the type of the content. And the quality of the content was impressive given the time it had taken to complete it.

We have continued to use this approach for nearly all of the eLearning we’ve developed.

I’ve also realised that the rapid approach offers several long-term benefits such as the following:

  • Overall reduction in development time (as long as all parties work to the project plan deliverables)
  • Reduced time and documentation at the design phase
  • Bulk of time required for the client is reduced at the review phase
  • Client gets to see the content sooner
  • A library of common interactions that can be selected and re-used.
  • More fluid and flexible approach to design.

I’m not going to say it has always been successful but with this experience, I’ve uncovered and developed a few tips and tricks to support the process along the way.


What does a rapid development model look like?

To better see these differences and how you can make them work for you, let’s look at this approach in more detail at each phase.

Analyse /Design: A workshop is run to bring everyone on the same page regarding business outcomes, key messages, learning outcomes, and approach (simulation, story based, game). From this meeting the Instructional Designer (ID) develops a high level design which determines the structure of the course, the topics, screen, and the content on each page – level of interactivity, type (e.g. video, click and reveal). The client then signs off on this design.

Phase Tip: Run a session to walk the client through the design and explain or even provide short details on each screen and how it relates back to their content. Examples of interactivity can help them to see how the page might look.

At this point you are looking for them to sign off on topics and sections. A key question you can ask to ensure this result is: Is the content and pages logical, in the right order, and speaks the basic idea of what the pages will be?

Develop: This is where the ID does their magic building the content from the high level design. The detailed instructional design is done as they build the course.

If there are videos and voice-overs these are scripted and signed off at the same time. Existing media and images are collected. They may also enlist the help of graphic designers if necessary.

Phase Tip: It can become evident here if content is lacking and/or requires culling. If the content has gaps, this is the time it will need to be collected. A workaround for this is to continue the build and highlight the need for more info in the content to be addressed in the Alpha review.

If there is too much content/or text, you may need to set their expectations before you provide the content. Note that it may be slightly different and they may need to wait and see the outcome first.

This normally sets the scene for an important discussion around critical and nice-to-have content that could sit somewhere else as a resource or job aid. However, it’s crucial that the SME, your source of information, provides all that needs to be in there!

Review: You need to allow a little more flexibility at the alpha review. Since this is the first time that the SME or client will see their content on screen.

The key to this approach is viewing the alpha like a first rough draft. Some re-work is to be expected.

Typical changes at the alpha are text and images. However, changes to the order of screens or topics may be required, or an interaction may not work well. This is a natural outcome because the client is seeing how the content flows for the first time.

Phase Tip: Set a time for key people to come together and review the content, rather than reviewing separately. Or even better, do both as this will save time.

Set the stage where individuals review before the meeting and then come together to share feedback. This provides the best opportunity for discussions and differences of opinion to be resolved on the spot where possible and all the feedback to be recorded into one document.

Conditions for success

I believe some specific conditions helped facilitate the success of this approach.

1. ID and developer are the same person
The ID can conceptualise the page in the high level design and then build in the authoring tool, going straight from design to development. They have a good understanding of the capability and the limitations of the software and can design to get the most from the tool.

2. You have a good relationship with the vendor/ID
You may have worked with them on a few courses and are happy with the work they deliver so there isn’t going to be any surprises with quality and outcomes. Going from high level design to an alpha version can seem like a leap of faith so this is where trust is very important.

3. Instructional design still plays a key role in the process
The ability to develop eLearning using authoring tools such as Articulate is now available to more people. But this doesn’t mean just anyone can create eLearning (although many like to think they can).

Developing quality content aimed at behavioural change or performance outcomes relies on skills and experience in adult learning theories and concepts, and understanding of the nature of how we learn via technology. The good news is these skills can be developed.

4. You have established templates and styles
Once you have produced a few courses/content this reduces development time and you can start to reuse existing interactions. Eventually you end up with a suite of re-usable interactions. And each time you create a new one you add to the catalogue.

5. The projects time frames are short/content has a short life span
Often you don’t have the time for a detailed design or storyboarding. The type of content can also lend itself to using this approach. A complex design process may not be required if it has a short life span, or does not require complex animations and simulations.

However in saying that, we used the rapid approach for all content development!

It’s great if you have a smooth seamless process that is working well for you now. If not, I hope this insight into my journey with rapid development has been helpful and triggered some reflections on your end.

What are your forays into rapid elearning design? Let’s compare notes.

If you enjoyed this post and would like to join our free community, you can sign up here.

About the Author

Photo of Author Kyle YoungKyle Young is an elearning and LMS consultant based in Brisbane Australia. Combining a solid mix of enterprise LMS experience and a passion for engaging elearning design, Kyle assists companies to build capability and competence. She has led and supported local and international LMS implementations for governments and large corporations across a variety of industries, and managed company elearning from set up through to establishment. Outside of work she wanders in nature, and teaches yoga and meditation to soothe the frazzled nerves of a modern life. You can find out more about Kyle on LinkedIn.