Having a background in graphic design and illustration, I have come across many opportunities to use document templates. One wouldn't always think that graphic design is a field that lends itself to templates, with art being an open-ended medium. But the more professional work I did, I found myself creating my own templates to work from, be it for animations, brand style guides, or laying out print pieces. Creating templates was essential for my work because it would maintain the quality of my deliverables while saving me time on each new project.
Storyboarding during the animation process begins once the concept and characters are developed and a script is decided upon. The script then informs the development of a storyboard. You can think of the storyboard as capturing the movement of the characters through a scene, and when each frame is connected, it'll bring the scene to life. As an artist, my job was to describe this movement in each scene with rough sketches of the characters, scenery, and perspectives.
My animation background easily translated to developing assets from eLearning storyboards. Like animation, the storyboards described the on-screen visuals, actions, and audience perspective. Whether for in-person, virtual, or hybrid learning experiences, storyboards gave structure, consistency, and depth to the deliverables.
Having worked with many different companies, each with its own version of a storyboard, I have begun to create my own storyboard template using what I've learned. I will share the template in a future blog post but wanted to touch on my early experience with creating design document templates. I believe the best templates come from experience. And when your own is lacking, I trust the experience of those around me. I love looking at examples of what has worked for other IDs in the past so I can learn from them and work their expertise into my own designs. I also believe that the best templates are adaptable, saleable, and easily understood. An ideal template contains enough detail and direction that both a novice and an expert can use it.
With my current experience, I have had the opportunity to write and document data for numerous training deliverables. I have some best practices when it comes to project documentation that I would like to share:
Consider your audience: It does not matter that you present information, it only matters that information is communicated. Therefore, consider your readers and meet them where they are. Use their jargon. Position yourself within their contexts and their needs. Make it as easy as possible for them to interpret.
Be concise: In that same vein, don't waste readers’ time. Explain what they need to know and nothing more. A wonderful book I read in grade school told the story of the author learning to write by going to his dad to edit his papers. His dad would say, "Well done, but make it three pages instead of five." And then during the next round of feedback, "Well done, but make it one page instead of three." This way the author learned to be direct and concise and attributes his success as a writer in being able to do so.
Ask yourself if a novice reader could understand: Indeed it is easy to become overly verbose when writing about something you are passionate and knowledgeable about. It is also easy to make assumptions about your audience and skim over background information you think is unworthy. And while this is the hardest practice to do, I think it is the most worthwhile. Assume the position of a reader who knows nothing of your process or project. Ask the questions you think are obvious. "Why did you do it this way?" "How did you get from point A to point B?" "What assumptions did you make here?" This was you can be sure that your client, coworker, or future self can be clued in to the thought processes and contexts you were operating in. And when in doubt, provide enough references for readers to find out answers for themselves.