Never thought to ask...

Mar 17, 2011

Gang--

I was speaking yesterday to a potential new client about voicing their next eLearning series, and through the conversation it occurred to me that outside of providing narrations, and what I've read here, I really don't know much about the process of building a course as a whole...at least on a nuts and bolts level.

Clearly it starts with research and writing and so forth, but what about the development process itself?  Do you start by building individual "slides," and insert additional elements, such as video/images/narrations, as you go?  Or do you gather everything up front and start building from there?

I actually downloaded a "free" eLearning creator not long ago and quickly came to the conclusion that what you folks do *cannot* be easy to learn, much less make look good and work effectively, so my hat's off to all of you for that. 

Thanks!

ab

7 Replies
Joe Deegan

Hi Andy,

I'm sure you will receive a wide range of answers as I would think everybody has their own "style" when it comes to the process of putting together an elearning course.  Here's a rough run down of the typical process I go through but this can change depending on the project.

  1. Develop objectives and Brainstorm with Client
  2. Research topic and brainstorm structure, navigation, look, etc.
  3. Storyboard in a Word document.
  4. Review storyboard with client.
  5. Make a rough prototype.  This is sometimes just text and key pieces of content.  Just trying to make the class usable but doesn't need to be pretty.
  6. Review prototype with client.  Although the prototype isn't pretty it's best to give the client something to test as early in the process as possible.  It's amazing how many new ideas or forgotten objectives pop up after testing a rough prototype.
  7. Revise prototype and develop into a more complete prototype to review the final structure and content with client.  It's good to get everything out on the table before spending a lot of time on the final touches.
  8. Develop final product and make it pretty.  After several reviews with your client you should know exactly what the client wants in the final product.

I put a heavy emphasis on reviewing prototypes so that I don't get to the end of the project and have to make heavy revisions.  It's easier to make revisions before a lot of work has been done.  Hope this helps.  Can't wait to see how others respond.

Leah Hemeon

I also want a "like" button. Joe, this is great. I'm going to add in that at the objectives phase I'm also working with my client (internal to our company) on the assessment. We use a competency structure so every course needs to be backed by a pretty rigorous assessment. Sometimes the assessment is built into the course and other times it's a stand-alone element that may not even be eLearning.

Lani Flores

RE: PROTOTYPING TIPS

I agree with Joe, prototyping the course is one of the critical steps in building successful eLearning.   A prototype is an effective framework for resolving any design, interaction, and course deployment decisions.     A prototype is particularly important when you are working with clients who must approve those decisions.

Here are the steps to prototyping:

1.  Select a learning object to prototype.  Ideally, you will choose a learning object that would include some common elements with other learning objects.  (Example: something with quizzes, video, pictures, etc. )

2.  Build some content for the learning object.  Since this  is a prototype, you don't need to create all the content.  A few sample slides will do.  Some things to consider when building the content.  Will the course be presented as:

a.  Situational style (scenario-based learning)

b.  Instructional style  (like textbook)

c.  For software training, is a software demo required?  Or guided screen shots sufficient?

3.  Prototype the overall design elements early, then lock the decision at this stage.  (Countless unproductive time are spent tweaking slides when instructional designers skip this step).    Here are the major elements I resolve during prototyping:

a.  Layout (Where should text, pictures, videos, title, instructions, appear?)

b.  Typography  

c.  Color scheme

d.  Branding (do logos need to be on the slide?  some clients insist on it)

e.  Realistic photos or cartoons acceptable?

f.   Narrated, or read, or both?

g.  Background (plain?  scenery? formal? informal? )

h.  Navigation (locked? branching? scenario-based? user can go anywhere?)

i.   Articulate Navigation:  Slide view?  Player visible?

j.   Music?  Feedback Sound?

4.  Create master slides based on the prototype

RE: APPROACH IN CONTENT CREATION

The typical process for creating content works from the bottom-up.

Step 1:  Build content

Step 2:  Create quizzes to test learner's understanding of content

Another way to approach content-creation (which I prefer but not always applicable) is top-down.   This approach is particularly useful

when the learner must pass an assessment test.

Step 1:  Build the test/quiz first

Step 2:  Create the content that will help learners pass the test

I prefer the top-down approach because it helps me focus on what the learners must learn.  And more importantly, in a situation where Instructional Designers are dealing with numerous reference materials or subject matter experts,  building the assessment/test first will guide the process of narrowing down what must be covered.  Conversely,  when you know what's in the test, it will help you identify the gaps in materials. 

Steve Flowers

This is our boilerplate for phases of delivery. Each project is a little different, so you've really got to go with client expectations balanced against the value propositions (talent) established by service provider. Each client and provider is different. If there's a misalignment here... Ouch.

I like to see a solution concept that outlines the patterns that will be used in the storyboarding phase before the prototype. This can describe the prototype in a narrative form. In my view, the prototype is a mechanism to mitigate risks and realign expectations. Sometimes, particularly with inexperienced customers, there is a belief that the sky is the limit. "You can do that, right?" -- the answer almost always is "of course, but $$ is an object, right?" A prototype can help to elaborate your solution concept and demonstrate the patterns planned to solve the problems discovered in earlier phases. The service provider knows what they are capable of, they also know what they're being paid. This solution concept narrative is one way to illustrate a vision for what we'll end up with before we get into the nitty-gritty bending metal phase. When I write a solution concept I frame up the problems, prioritize those problems, and write a narrative for the solution that parallels an advertisement. How would I sell this thing on TV to make someone want to buy it? What kind of doubts might be raised? How would I answer those doubts?

The pre-design analysis identifies the "big problem" (terminal objective(s)) the course seeks to solve as well as the audience details and resources that will be used to construct the other deliverables. I see the design document as the formal narrative that describes the big problem, breaks that big problem down into smaller problems, and proposes a high level solution strategy for addressing these problems. Sometimes I'll also include some content scoping during the pre-design analysis and design document phases (what facts, concepts, principles, or procedures are we going to address?) We REALLY want / need to know the scope of actions and content before defining how we're going to measure acquisition of the defined skill! Discovering content during the storyboard phase seems backwards to me.

The other thing I like to do is develop incrementally. My development will release in drafts. Once we get approval on the boards, I'll drop the narration into a text to speech engine for scratch audio. I'll do rough elaboration on any exercises and illustrations to get a quick view of the experience. Think animatics that are used in the development of movie storyboards. It's MUCH easier to see the how the experience plays out with rough visuals / audio than it is with a text based description. Most of the time we'll make minor tweaks here and there, a major tweak in a couple of cases and finalize everything in draft form before commiting to final narration. Rough iterations (successive approximation described by Joe above) are better than polish iterations. I may have 3 or 4 iterations of rough adjustments before applying the polish sweep.

Also... this seems like a waterfall, over the wall process. It is and it isn't. Most deliveries have dependancies. Design is the overarching task. To me, design is a state of mind applied to solve a set of problems. Normally an instructional media project requires quite a few disciplines to identify and solve the big and small problems presented by the original request. Even though it looks like we're doing one thing after another, the key to success is maintaining a constant "state of analysis" - looking for potential problems and solving them within the resources you have without making bigger problems. Big rocks into smaller rocks. Small rocks into sand.

This discussion is closed. You can start a new discussion or contact Articulate Support.