One of the key decisions you’ll make when developing eLearning is when to swap the simplicity of designing in a document format and start building content in your authoring tool.
The approach you take will be dictated by a number of factors: the kind of team you’re working with, how well you know the subject matter, who’s going to be signing off on it, what development tools you’re using, and so on.
Getting your content up on a screen early has both pros and cons. There are a number of factors to take into account when deciding on the best compromise for your project.
Defining the Structure
In the early stages of the project you’ll be most concerned with getting the structure of your eLearning right. It helps to get this as close to the final design as possible early on. The further you progress through the project, the more time is invested in building your eLearning and the more effort is required to change things around.
A word document is often used at this stage to layout bullet points showing the learning objectives and how they will be structured. If you’re building a more complicated course, such as a scenario, you might also use a flow chart, sticky notes or a mind map to help organize thoughts.
Reviewing your design will also help you decide on the best approach. It’s likely you’ll need to get it reviewed and approved by someone else, perhaps the project sponsor, subject matter experts or your own boss.
As a learning professional you may be able to easily visualise how things will look and work on screen from your document. Just keep in mind that the people reviewing and approving your work may not have the same concepts and experience as you.
Using an up-to-date authoring tool, like Storyline, makes it easy to move pages around and reorder things using the Story View. This makes it simpler to share via email and for stakeholders to give input and make any changes to the proposed structure.
Putting in the detail
The next stage is where you will typically produce a set of blueprints, scripts, storyboards, or other similarly named, detailed representations of the finished learning. This includes all the details of the text on screen, descriptions of images and how interactions will work, script for voiceover or video sections, and so forth.
At this stage we will normally take one of three different routes
Carry on with a Word document – typically this document will have one page per screen, with a description of the screen contents laid out in a table format. There can also be example graphics and diagrams added.
Create a PowerPoint storyboard – this will have one slide per screen and gives more scope to produce a visual representation of the layout, with graphics and basic animation to show how things will work. There is also scope to import this directly into Storyline and automate some aspects of producing the design at a later stage.
Build a Storyline prototype – here we design straight into Storyline, building the structure along with some elements of the interactions and adding rough graphics and diagrams.
So how do we decide which approach to take? These are some of the factors we consider to help us choose
Stakeholder preference – sometimes the people involved in your project will have a preference on how they’d like to review the blueprint. For example, they may want to use their word processor’s track changes feature to get comments from a wide stakeholder group.
Stakeholder Expectations – the people involved in your project will start out with expectations of what the content will look like. These can be set by good or bad examples of eLearning they previously experienced, or could be from an amazing interactive experience they’ve seen in a sales pitch. Either way, it’s often when they first see it on screen that they’ll get the full understanding of how the content is going to look like. Creating scripts in documents can extend this period of mismatched expectations and leaves less time to get things on track if the learning is not what they are expecting. A storyboard built in PowerPoint or a Storyline prototype can give a much clearer view of the final layout.
Content readiness – If you have a really detailed understanding of what the content is going to be then there is less risk of rework when you begin to build in your authoring tool. If there is still uncertainty about the scope and the detail, then it makes sense to keep things simple until everything has come to an agreement.
Timescales – If the eLearning needs to be delivered in a hurry, cutting out a cycle of review and amend on paper, then going straight to screen can accelerate things.
A picture paints a thousand words – some stakeholders will want to leave the detail of the imagery to the development team, while others have a very clear view of what they want. If you’re working with the latter and you design on paper, you may find that you end up changing a lot of the images you’ve chosen or created later in the project. No matter how carefully you describe an image, there are a thousand ways it can be misinterpreted. Maybe the room colours are off brand, the computer is the wrong type, or the people in the shot are too happy, sad or whatever it may be. On some projects, cutting out the description stage and going straight to visual presentation can avoid a review and adjust a cycle that might create rework further down the schedule.
Finding the right compromise
The right path to take will depend on finding the right compromise between the various factors, some of which will often become clear only with hindsight.
The good news is that with the latest generation of authoring tools like Storyline 2, making changes to the structure and interactivity of your content is now quick and easy. This freedom allows us to work in more agile ways, develop on screen earlier in the process and using iterative prototyping.
The stakeholders get a clear view of what the content will be like early on, they have more meaningful input into the process and we end up with a great piece of eLearning.