The Learning & Development industry is a vast array of many disciplines and technologies. A deeper look into each major discipline and we see an enormous amount of energy in order to learn the skills to be proficient.
Looking at Instructional Design as it applies to elearning where there are many theories, models and methodologies, it that take years of practice to become proficient. Visual Design and the fundamentals of composition, color and fonts is just scratching the surface of the discipline. User Experience Design and Interaction Design both have a lot of work and practice to become proficient. Add the skills and knowledge of current technologies where it all comes together in development and the world of elearning can seem overwhelming.
So how does one become proficient and designing and developing elearning?
I can’t answer that for you other than being proficient is a matter of time and practice while exploring, testing and learning new ideas. Only you can define your level of knowledge and skills. What if we could help our own processes on the road to being more proficient by being more efficient?
Efficient: achieving maximum productivity with minimum wasted effort or expense.
Being efficient also takes time and experience to learn all those little nuances and processes in your organization, your work team, your own workflow, and evaluating your own level of skill. Documenting those processes along the way helps isolate inconsistencies and/or good practices eventually working toward efficient processes that shorten the lifecycle of a project.
Enter the Storyboard Workbook. Without getting into semantics of defining a workbook or whether you support the storyboarding process or not, let’s agree for the sake of this post that it is a collection of documents that support the design and development of an elearning project.
Contents of a Storyboard Workbook is completely subjective based on the project. At a minimum the main storyboard document seems appropriate, but there are more document types we can add and there’s no exact type or number of documents as each project will dictate.
The following are storyboard documents I use on a regular baasis: Recommended and Optional documents.
Recommended:
- Main Storyboard – This document is the overall structure of the design. This may or may not include course title, page/screen numbering, onscreen text, narration, and some development notes. Typically the most commonly used regardless of layout.
- Visual Storyboard – this document displays the overall design of the project’s navigation path. How the project looks at a high level allows stakeholders to see the learning path as well as content accessed globally. Also aides in seeing potential dead ends, endless loops, or confusing or redundant paths.
- Style Guide – this documents the standards of the project from color palettes, the fonts and their sizes to global assets such as navigation buttons and their positioning in the user interface.
Optional:
- Script – in some cases (most) the narration script requires a lot of real estate in a document. Especially when contracting outside voice talent, removing all the noise such as development notes helps the actor focus on the script, pronunciation instructions, and cue points.
- Media – This document could be used to list all the media assets as a way to catalog or index their usage. When sourcing images from stock websites, the image is associated with a file number and this document helps maintain the source if the image needs to be re-acquired.
- Video – If a project requires a video shoot, there are a lot of details that would overwhelm the main storyboard. This document lays out the scenes, actors, camera angles as well as props and settings.
- Interaction – A simple drag and drop or click and reveal may not need their own storyboard. This document is for more complex designs that involve behaviors such as branching choices, multiple paths or interactive video and assessments.
- Menu/Navigation – Most of the common authoring tools for elearning can publish a standard user interface or skin where a separate document may not be needed. This document is for custom menu designs that at a minimum accomplishes two things – navigation structure and navigation behaviors.
- Animation – Not to be confused with animation effects on a specific screen, this document is similar to a Video storyboard that shows scenes, motion, timing and pacing.
Each of the above Storyboard documents that make up a workbook for a project does take extra planning and effort and there is no rule to how many or how few. Again, project dictates. Look at the following three questions and based on your current workflow, answer them as honestly as you can:
- How often have you worked on a project that has stalled out because of design considerations in the middle of development?
- When asked to revisit a project several months later to apply edits for an updated version, do you spend unnecessary time re-learning how the project was developed?
- If you work on a team and you’re asked to pick up a project currently in development by someone else, can you step into their role and continue to work on that project?
If you answered “never”, “none”, and “yes” to the above questions then I commend you for having a solid and refined workflow processes in place!
If you answered those questions differently or they have you thinking differently, then I encourage you to try implementing the documenting process I call the Storyboard Workbook.
Keep in mind that storyboarding is a process; not a rule While there are templates to get started, storyboards are living documents that can be standardized by a number of things such as organizational guidelines, branding standards, and even customized to the authoring tool you use.
Yes, documenting the details takes more time, but the benefits outweigh the effort.
Thank you for reading this far. My week at DevLearn will follow this theme first in my pre-conference workshop, Storyboard to Storyline (not too late to register!) I’m pulling the Style Guide out of the above mentioned workbook and delivering a session on Wednesday afternoon titled, Style Guides: The Unsung Hero of Elearning Development. Then on Thursday evening I’m excited to show off a custom project and its Storyboard Workbook at DemoFest.
See you next week!
Veronica says
It seems I am hooked to your blog at the moment Kevin!
This is a very useful post. It pays off to document all aspects of a project, and yet it is hard to be consistent about it. I remember while back reading your posts about the PWP in action piece you did (which was incredible BTW) and it was so helpful to see the process and all the ups and downs, forwards and backwards.
Thanks again!
Kevin Thorn says
Thanks Veronica!
Every new habit is hard to be consistent which is essentially what the process of documenting and/or storyboarding an elearning project is all about. If the process becomes part of every project then you will have the same feeling about it when you don’t include it – hard not to.
I’ve been doing it for so long now that I get nervous if I get behind with the documents. More importantly, I have found that writing about and during a project solidifies the design process as well as a permanent documented record. It has helped me in growing my skills if nothing else.
kristie mubarak says
I REALLY appreciate this post. I’m wondering if you wouldn’t mind sharing an example? You are always so insightful in how you approach your work and I struggle with documenting my workflow, I can be creative but it would be really neat to see how a master does it.
Rex Miller says
Articles that have significant and savvy remarks are more agreeable, at any rate to me. It’s fascinating to peruse what other individuals thought and how it identifies with them or their customers, as their point of view could help you later on.
Thanks for sharing with us.
Rex Miller | buy coursework essays