As I look back on the last year or so, I realize I have developed a somewhat reusable process for almost every project I do. Often I am working between subject matter experts (AKA Research Experts) and the creative people that make our dreams come true (AKA Web Developers and Programmers). I will admit, I am a fan of my process and am sharing for this reason.
Note that I work on everything up until the programming and building of a course or program. There is a team of web developers and programmers that I work with to make things happen. So I do not do the development or programming myself.
Provided are descriptions of the documents or forms I use for instructional design. I find it is easiest when I do them in order and get a sign-off, either verbal or in email, from the project head before continuing to the next step. This is a good way to do the iterative process and make sure when something changes it fits the original learning outcomes and goals.
Documents-
- Project Design Overview– This document pulls together the design and programming details for projects. Included are many details from the original business or project agreement (many times a grant for me), programming details, and the beginnings of program flow and design. It is useful when working with the web developers and designers for answering questions about function, needs, and deliverables.
- Personas– These outline the target users or learners of the programs. Details may include name, picture, job title, hobbies, age, ethnicity, race, gender, level of education, previous work, job skills, educational attitudes, pet peeves, and learning styles. Personas offer a chance to design from the perspective of the target users of the program or course. Sometimes these are included in the Project Design Overview but not always.
- Application Flow– A flow is required for many projects to identify overall function of the program. Often there are many iterations of this flow. This is a helpful tool when determining what is needed for content, coding, and to meet research deliverables. This eventually is turned into a “sitemap” used by the developers to build out.
- Sample Frames– Used for preliminary brain storming, sample frames can offer insight into what the parts of the program may include. Parts may include drag and drop activities, videos, buttons, location-based search functions, in-app purchases, and other features. These eventually turn into official wireframes used by the web programmers and developers for building out the functioning programs.
- Alignment Chart– This chart is only needed when a learning outcome is addressed. It is used to align learning activities and assessments with learning objectives and outcomes. This chart is very helpful in determining where information can be combined, excluding portions that are repetitive or unneeded, and saving development time and money. My alignment chart is based on Horton’s Absorb, Do, Connect activities and learning objectives.
- Content Template– A template is created based on the application flow. An alignment chart is especially helpful when there is a learning outcome. Content templates are extremely useful in collecting content from all subject matter experts and passing it to the programmers. Templates have the same exact sections and information blanks as the flow to direct placement in the program. Of great importance is finishing all text-based edits prior to passing to the programmers. This is to eliminate lengthy editing sessions that could have been done prior to programming.
Some people may call these something different or have a different understanding of their uses and functions. Of course, I am always open to new ideas and suggestions. Feel free to leave a comment if you have something to add.
