E-Learning Heroes - Advice and ideas from the Articulate Community

Hello all,

The biggest problem I have with building an Elearning course is planning. I understand that it is foolish to jump right in and start building the course slide by slide. However I'm unable to properly utilize storyboards effectively. I've found many storyboard templates and examples, but in almost every case my storyboard just turns into a script. Not being a graphical designer, I'm completely incapable of "building" the visuals for the course in my head.

Storyboard examples I've seen often have things like: "color stripes with relevant picture at the top fade in the out synced with narration. Large downward arrow moves from right to left across screen demonstrating yada yada yada". How do people know what to write here without actually building the course first? I'm unable to understand how people know what graphics/animations they're going to have before building a slide and just experimenting with random images etc.

So how do you build your storyboard? How did you learn to visualize your course and put it into words? what tips do you have for a newcomer?

Hi Drew - that's a great question! I think you'll find a lot of different opinions out there.

For me personally, since it's so easy to work directly in PowerPoint & Articulate Studio, most of the time I tend to prototype a course directly in the authoring tool, rather than spend a lot of time storyboarding. I usually start out by building just a "roadmap" structure with simple boxes and arrows, to show the course flow...and as long as that looks good to the SMEs or project sponsor, I like to get right into prototyping the slides and the actual course structure.

Don't get me wrong, the prototype slides usually look quite unpolished in the beginning, and they might contain just lame placeholders for images, etc. ... but doing it this way allows me to build out the structure, branching, and even record a rough-cut of the narration (along with some verbal notes to my SMEs). This makes it easier for both me and my SMEs to get a feel for how the course will ultimately look & behave, as compared to slogging through a written document that just contains descriptions of how each slide will look and function. Plus, if the review team is okay with the prototype, then a lot of the work is already done... from there, it's basically a matter of cleaning up the visual design, swapping in the appropriate images, etc.

I do think storyboards can be really helpful, though, for some projects where you need all sorts of layers of approval before you move on to each step in the development process. Or in some e-learning teams, because of the way the work is divided, a storyboard can really make a lot of sense if lots of different people will touch the project; that way everyone is clear on how each part of the course should be designed and developed.

Have you checked out any of the storyboard samples in the downloads area? http://community.articulate.com/downloads/g/storyboards/default.aspx

There are also a couple good storyboard-related blog posts by Articulate users that you might find interesting:

Kevin Thorn's 6 Tips for Managing & Developing E-learning Projects

David Becker's E-Learning Storyboarding 101

Drew,

I can relate to what you are saying. I have tried using storyboard templates and feel limited due to my lack of artisitic ability. Like Jeanette, I use PowerPoint as my "storyboard".

What I do first is to create an outline on a white board where I can make notes or even draw pictures (I am NOT an artist or graphical designer, so it is usually stick figures or VERY crude images). I then create a PowerPoint and begin by writing what I want to say - the first draft of the script, if you will - in the slide notes field. I then look for graphics that are appropriate to that slide, or create text boxes, etc..., depending on what is needed, or use a placeholder image or a text box telling me that a specific image is needed here. If I plan to use an Engage interaction, I'll note in the slide notes what I want to do with the interaction. As I go thourgh the process, I'll make changes to individual slides, add or delete slides or rearrange them as needed until I get a first draft. I submit the slide deck to the SME's for review and feedback. Based on that I refine the material, resubmit, until I get final approval. I then apply interactions, record narrations, and publish. I get a review team to do a run though the published course, make any necessary edits, republish and launch.

I had the same problem with the story board templates that I saw. So I just outline the course now in Powerpoint - each slide is a placeholder with an written objective for what I want the slide to do, and then I work it from there. Still a newbie at this too, so if you come across a better way to do this, I'd love to see it.

The methods described above can be a great way to "outline" your mental model and get a feel for flow and learner experience. This method can also be helpful for "rapid prototyping" of elements that can be tested with your SME and audience. In a quick follow-on response I'll describe some instances and methods where I use PowerPoint to illustrate concepts, flow, and instructional narrative. This response will focus on the stuff that I think should really happen before the nitty-gritty design phase.

I feel strongly that starting in PowerPoint or in a storyboard for that matter isn't always the best way to begin a project. Sometimes this can lead to designs falling into the dreaded *content trap*. This is where your design revolves around content presentation rather than learning processes, outcomes, tasks, etc.. I think sometimes the difficulty folks have with storyboarding and design is a lack of preparation and a misguided focus.

Here's what works for me. You may already have considered these elements in your training needs analysis, but if you haven't -- it's a good process to frame up your solution cultivation. The foundations for the design and all of the variables that inform this design "sprout" from this build-up process that I use. As those above, I may quickly prototype sequences in PowerPoint to organize thoughts and include these artifacts in my design documentation.

1. Examine the primary factors. These considerations should frame the foundation of your solution:
   - What are the performance and business requirements? If you could only have 1 positive outcome out of your training product, what would that be?
   - What tasks do you want the learner to be able to perform that they are currently not willing or able to perform to the level defined in your performance and business requirement?
   - What steps go into these tasks? Consider more than the observable steps. What is the learner thinking about? What concepts must be grasped, and to what level?
   - What level of change is expected? Are you expected to train a from-zero novice to the expert level? Is the target for this solution foundational, readiness, or proficiency?
   - Is an eLearning solution indicated or counterindicated by any factors?
2. Examine the secondary factors. These further inform design decisions:
   - What's the solution context? Are your learners learning new skills, extending existing skills, refreshing existing skills, recalling and applying skills, updating skills after a process or system change, leveraging tools in lieu of training, or responding to an urgent requirement to perform a new task?
   - What are the resource constraints? Budget, cost of solution to cheaper solutions, timing, etc...
   - Any special technology constraints or requirements?
   - Who is your audience?

We use a set of worksheets to capture these elements even before we enter pre-design analysis before we start any design work. We're a pretty big outfit and we contract quite a bit of work, so these are fairly necessary for consistency and working right to prevent a content-focused-pile-of-course. Many designers don't like to be tied down by process. In my view, process can be a dangerous thing to avoid. Ignoring process and jumping straight to presentation design can sometimes result in wasted design and development time. Or worse... wasted learner's time.

• Performance Requirement and Tasks Worksheet
• eLearning Suitability Indicators Worksheet
• Stakeholder Worksheet
• Objective Mapping Worksheet (Maps performance tasks to cognitive / covert tasks to in-course objectives and captures task requirements)
• Interactions Worksheet (Maps objectives to core interactions. We tend to focus first on practice activities. If everything else falls off the table, we have put the best energy into those things that matter most).
• Assessment Items Worksheet (Maps objectives to assessment items and documents criticality and references)
• Curriculum / Lesson Worksheet (Designates modular course elements, minimum score requirements, whether they are tracked)

This might seem like a lot of effort. It's not as much as it seems. This is designed to get folks out of the content-centric mindset and thinking about the stuff that matters most. Once we've documented the driving factors for the solution we get into the real process deliverables. Like I said, we contract quite a bit of stuff so we require incremental deliveries that gradually increase in scope. These include:

• Project plan (overview of the project, deliverables / milestones, risk management / quality control expectations, etc..) This is something we alwaysproduce. It's not always a big thing to do but it's the first design deliverable out the gate (the worksheets above are pre-design).
• Design document (solution description, training requirements, tasks and objectives transferred from the pre-design worksheets, design approach / strategies / assumptions, outstanding questions for the SME / customer). This also isn't a huge document. But this is the one small thing that describes the concept and promise for the course / solution. Jumping right into a design without having an anchoring concept for the design or a description of the highlights of the experience places the designer at a significant disadvantage.
• Assessment plan (assessment strategy, packaging assumptions, objective strategy map, test items, special considerations). Too often we see the content-centric thought process leads to content first and a cursory sweep of that content for assessment questions. To me, this is backwards. So we require our assessment strategy up front. This frames up how the assessment will be carried out (which usually aligns closely with the tasks and practice activities, so this isn't too tough to produce either).
• Design flow. This document extends the design document with a high level mapping of specific elements. This tells the story of the course in a VERY brief and high level narrative that couples solution decisions with rationale. For example, if our audience analysis revealed that learners would have limited time to practice with a piece of equipment, we might describe a set of virtual task simulations as a center-piece for a few of our topics. This document is simple and represents segments, strategy, and features. This can be represented as a narrative and / or flow-chart.

We also require a functional prototype before we get into storyboarding. For the scope of the projects we commission, it's pretty important for us to have high confidence that the contract design and development staff *gets it*. Once we're confident that design can proceed without a hitch, we ramp into the storyboard development. Again, our projects are large scope. Smaller scope projects might have a different ramp in.

Our storyboard requirements are:

• Format the boards appropriately for the review audience. Most of our reviewers are busy and reviewing boards simply isn't a priority. Don't crowd the format. Dont include irrelevant fields (most reviewers want to know how it will function, not how the designer wants the programmer to program it). Different groups may have different preferences. For example, a legal / compliance review staff is going to like explicit verbiage for any text included and might prefer this in a straight document over a PPT presentation.
• Extend the design document and design flow. SB's are a granular narrative representation of the learning experience but must tie back to the artifacts that inform decisions documented by the storyboards.

That's it. We don't dictate format, though we do offer a sample. This sample looks something like this for a screen unit presentation type of course:

The big point of this reply is to emphasize that while storyboarding is good, it's harder than it needs to be if pre-design activities aren't tended to. I'll follow this one up with the way I "storyboard" when working with clients.

To me, storyboarding isn't a one level linear process. It's not a process of lining up linear blocks or figuring out fancy ways to decorate a presentation. Done right, I think it's so much more than that. The planning and design (problem solving process) is deep and wide. On one level storyboarding is a method to organize goals. On another it's a way to map those goals to the learning experience. Taken a bit further it's a means to capture the finite details of an explanation. It's an exercise as much as it is an artifact. For me, it's almost always best to stay away from technology as long as possible. Technology tends to taint the process more than a brain, a pencil, and a big sheet of construction paper.

One process that I find helpful when I'm designing is something I call "Left to Right". I use this method with SME's and it usually works out well as we refine the design as it grows, easily correcting most big assumptions before we spend a lot of time iterating through design activities. The Left to Right Activity is iterative and basically equates to an outlined map of the high level goals to the low level details. Here's a rough and simple table that represents the concept of this activity:

We might start one session just examining the first column on the left. Then another that expands each of these elements until we've exposed all of the elements that support the goal. Once all of this stuff is in place, I move onto a collaborative build of the rough experience narrative. As indicated above, this describes the learning experience in really rough terms. This does a couple of things for me. First, it involves the SME's in the design process. SME's that have ownership in these sessions have been less likely to change direction later. Second, it provides a really fertile starting place for refining iterations of the design. This is low tech and relatively low effort. The SME shares in the work and feeds the process with creative energy. It works pretty well for me.

I might jump from here into dropping quick descriptions of activities, explanations, and sequences in PowerPoint for a rapid-turn representation of the experience. Sometimes seeing it chunked down into screens changes what the SME thinks of the experience narrative. It's a good starting place.

I might also use PowerPoint or Fireworks to produce "storystrips". These strips represent sequences or themes for communicating concepts. Most folks don't know that you can make PowerPoint slides REALLY wide. I use square strip units and it's easy to update these if I run out. If I needed 15 strip transitions, I'd make the PPT slide width 15x as wide as the height. Under the design tab, click Page Setup.  The default height is 7.5 inches. I make this 3.75 inches so I can have a wider strip.  The max width is 56 inches in PPT 2007. I end up with a 15 unit wide strip. This is helpful when I want to represent a transitioned series of graphics and don't want to have to flip through pages. This is also great for really extensive flowcharts that you want to be able to represent vertically or horizontally when capturing process flows.

This graphic is an exported Fireworks output. I ended up using these graphic representations throughout a short respiratory protection course. Having everything in one place in a theme-strip helped to unify the theme and feed the process.

Storyboarding is a way to incrementally represent the design team's vision for the learning experience. The methods you use to work through the problem solving process (I see design as a problem solving exercise) will depend entirely on the problems you're encountering. Using design to solve real problems is going to give you better results than using them to flemish or decorate. The type of information you are conveying is also a factor. A fact may be presented differently (hopefully in the context of application) than a concept or procedure.

Talk through it in your head, with your team, or on paper. Write down the learning challenges.  Defining your design challenges in terms of questions can be helpful. General questions can be helpful to frame things up at a higher level:

• What's hard about learning this?
• What are the consequences of getting it wrong?

Specific questions are also pretty helpful when you get down to the details. Talking through the problems can be really helpful:

• This new concept is critical. How can we make sure the learner notices it and *gets it*?
• It's similar to X. But differs from X in Y way. Can we leverage that similarity that most learners already get? Could that get us into trouble?
• The SME told a story that evoked a metaphor. That could be helpful, how could we use that in a natural way?
• Let me sketch some ideas in my notebook for a few minutes. Anything jumping off the page?
• Can we simplify this to a memorable message?
• Do we need to "warm this up" so that it resonates?

I love design as a problem solving discipline. I don't see content organization or content treatment as the key element of design, yet organization and treatment are where ID folks tend to spend the bulk of their energy. Copy and paste or cookie cutter pattern application aren't necessarily design activities. It's rough work. I think that's what you're seeing. Break things down into smaller bits - work on defining the problems first - it'll come together

Wow, thank you all for your replies. You all have offered a lot of information that I'm sure someone in my situation can benefit from. Steve I'm very interested in your structured approach. Are those four documents you create from a template? would you be able to share a generic outline of a project plan for example?

I've realized that maybe storyboarding isn't my biggest problem, but overall planning. I'm a one man department with little or no access to SMEs other than the general manager of the company who started my position with "we need training for everything from customer service to loading trailers". which resulted in me spinning in circles for three months just rapid prototyping. Now that I've come full circle and realized that I need to focus on ONE department (brand new employees starting in customer service), I really wish I had several documents like you suggested to help me out.

Like I said in my original post, I'm the furthest thing from an artist or designer so I really like steve's idea of focusing on learning outcomes etc rather than presentation. My course my look hideous, but at least it gets the job done!

Heres an example of an unfinished prototype focusing on just teaching new employees about our software. In the end I plan on creating a 1-2 hour course that will teach everything a new employee will need to start, and will include this topic as a section.

http://dl.dropbox.com/u/29867310/player.html

Thank you again for all your wisdom!