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
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.
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.
We need a Like button. I think you are on the button Joe! I suggested it be the answer.
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.
Thank you! It's nice to be liked : ) Michael Allen's "Guide to eLearning" is a great book to learn more about using prototypes. He describes a similar approach called Successive Approximation that I love.
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.
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.
Thanks for the insights, gang...
To quote a radio commercial I once heard, in which a man walks into a cellular phone store and declared "I'd like to change my calling plan, please," the employee looked up from his game of Windows Solitaire and replied:
"...yeah...that's a LOT of WORK..."
Good for you.
ab
This discussion is closed. You can start a new discussion or contact Articulate Support.