An important part of the instructional design process is to document your design plan. However, documenting the vision you have in your mind is not always easy. Your client, stakeholders, funders, and other interested parties need to see the vision in writing in order to determine if the proposed training meets their needs and addresses the specific problem being presented. Additionally, the completed design document becomes the road map you use during development and keeps you honest throughout the process. It may also be used by other developers who may be contributing to the development of the course.
This week I set out to create a design document for a course designed to teach new college students success skills. My first thought was, “I got this. I am really familiar with the course content and I have designed online courses before so completing this assignment should be easy.” The reality turned out much different. One of the first things I realized is that the design document format itself may need to change depending on your audience. As a graduate student in learning technologies, I have taken several courses that required me to create a design document. Each instructor has a slightly different expectation of what the design document should look like. Additionally, I work as a content developer and my employer has a different design document expectation than my instructors. In this course, the instructor did not specify a specific format. He provided requirements for the document and left it to me to decide how to present the information. Without a specific guide, I struggled to determine which layout to use and which sections to include (beyond the stated requirements). As a result, I over delivered in some areas and under delivered in others.
My design document had some sections that were redundant. I was trying to hard and ended up saying the same thing in more than one way. This is a waste of time and does not help others understand what you are trying to accomplish. I also used labels for some of the sections that were not explicit enough. For example instead of labeling the goals sections as Goals, I labeled it as Learning Outcomes. This was confusing for both the instructor and the peer reviewer. My take-a-way from this mistake is to just call a thing what it is and keep it simple.
Another area I under delivered on was the assessment and evaluation sections. I included a summary statement and after reviewing the feedback I received, I realized that I could have done a better job of providing more details. A real client or stakeholder want to know how they are going to be able to assess the return on investment. In other words, how are they going to know if the training does what it says it is going to do, and how are they going to know if the way it is presented to the learners is engaging and enhances learning or distracts from learning.
My final product was definitely better than my original draft. I would feel confident sending this design document to a paying client and I believe that they would be able to positively, and enthusiastically sign-off on the project. But, I can’t take full credit alone. The most important lesson I learned is that it is best to share often and share early. Feedback from others helps identify gaps, mistakes, and opportunities for improvement that the original developer would otherwise not be aware of.