What’s Missing from Your Instructional Design Documentation?

I managed instructional designers for over a decade and I have been facilitating an elearning instructional design (ID) practicum for a local university the past few years. Over the course of my career, I have reviewed many ID documents spanning the range of quality from excellent to poor. It’s common to find even good instructional designers get right down to storyboarding and scripting the content with little information about the general ID of the curriculum to guide them. Subsequently, there are some elements that are very valuable to include yet are often left out of ID documentation.

There is no lack of information about, and templates of, the basics of creating storyboards for elearning on the World Wide Web. Instead of duplicating that information, I will focus on the higher level information about ID that is too often missing from the documentation. There are a number of ID elements I recommend documenting before designing the content itself. I’ll explain why this information is valuable to the development team and other stakeholders who reference the documentation.

Title and description

It may seem obvious but you should document the official title of the curriculum (and a course code, if your organization uses one). When you describe the curriculum, include a summary like you find in a typical course catalog at a local university. The marketing department can copy the course description from the ID documentation and paste it into promotional materials and a learning administrator can copy the title, course code, and description into the LMS.

Needs analysis and desired outcomes

It’s helpful to report the findings of the needs analysis (if one was performed) and explicitly document the outcomes the organization desires so instructional designers and developers know what the organization wants to accomplish with the course. That puts in everyone’s mind why they’re developing the course in the first place to help keep the content focused on its ultimate purpose.

Although you should also document the learning objectives, that’s not what I’m referring to here. The desired outcomes are the challenges the organization wants to eliminate or the opportunities it wants to take advantage of as a result of the staff development from the course. Ideally, they should be expressed as measurable objectives so you can do Level 4 testing after a critical mass of learners have completed the curriculum.

Audience analysis

Many instructional designers document the audience “analysis” by simply identifying who the target audience is. But a true analysis reports the characteristics that are commonly found in the audience. Those characteristics might include anything from the typical learner’s technical competency using elearning to foundational knowledge they’ll likely have before studying the curriculum. If it’s relevant, the analysis should include the demographics of the audience. One effective way to do this is to create a persona to represent the typical learner in the target audience and describe the persona as a fictitious learner, right down to his or her name and title. This gives the instructional designer insight to apply as he or she designs the details of the curriculum.

Course outline

This gives the developers a hierarchical perspective on the structure of the curriculum. It also helps the learner understand the scope of the course. It’s a more important criterion for large curricula.

Instructional approach and assessment strategy

To guide the instructional designer on what is appropriate content, document the instructional approach to be applied in the content and what assessment strategy to use for the curriculum. By “instructional approach,” I don’t mean the elearning modality or blended learning elements to be used (although that too should be documented). It’s common to base an instructional approach on Bloom’s taxonomy. For software training, it might be a “tell me, show me, let me” approach. And an assessment strategy is more than just stating how many questions a quiz will have. A classic tool used to create an assessment strategy is the Kirkpatrick Model (although there are others you could apply). There are many models that can be used for both the instructional approach and assessment strategy, so choose what works for your curriculum and document it.

User interface (UI)

I recommend documenting the design of the elearning’s UI in the high-level documentation. The UI is made up of all the visible elements of the courseware that are not content (e.g. navigation, user controls, position of titles, logo, buttons, etc.) and recur in multiple or all screens. The UI should be consistent from screen to screen, regardless of the content presented, so it can be documented just once in the high-level ID documentation with instructions to apply it throughout the courseware. That way, the UI design does not have to be repeated in the ID documentation for every screen and the storyboards can focus on the content. A wireframe is typically used for documenting a UI.

Style guide

Apply a style guide in the curriculum’s content but do not incorporate the full guide in the ID documentation. For consistency across all curricula, you would want your style guide to be standardized on all projects. In fact, all of your organization’s documents should have a consistent style, so you might find that the marketing or corporate communications department has already created a style guide that can be applied to elearning with few modifications. When the formal style guide is established, save it on the local area network (LAN). Then when you document the ID of a specific curriculum, simply reference the style guides’ location on the organization’s LAN and instruct the developers to apply it to the courseware. That way, you don’t have to copy the entire style guide over and over again every time you document a new curriculum. There are three broad areas for which to establish styles:

  • editorial
  • audio and/or visual
  • text formatting

Quality assurance (QA) plan

QA must be planned as part of the development project for quality control to be consistent. Validating the instructional design allows anyone referencing the documentation to understand the purpose each component of the course serves.

System requirements

Document the courseware’s technical system requirements for the learner in detail. Include all factors that will be supported in production such as:

  • browser(s) and version
  • audio card and speakers
  • microphone (synchronous virtual classroom)
  • Adobe Flash and/or HTML 5
  • iOS and/or Android
  • mobile form factor (i.e. tablet and/or smartphone)

This information is critical for quality assurance so you know what platforms to test the courseware on. If there’s a technical constraint, documenting the technical requirements helps identify it. It’s used to notify learners what technology they will need to take the course. The help desk also needs this information so they know what technical support will be expected from them.

There are a few other elements that can be informative but are not needed in all cases. If they apply in your curriculum, consider documenting the following items.

  • Include an executive summary for executive management who will review the ID documentation.
  • If you want to express the learning objectives to the learners with a “what’s in it for me?” approach, document the value proposition for the learners.
  • If there are any prerequisite or follow­-on courses, document them.
  • Be sure to list any certifications associated with the curriculum.
  • Obtain the signatures of the stakeholders approving the ID to verify that there’s a shared understanding of what is being developed and provide a baseline for change management.
  • A change log communicates any changes in the ID that occur during development to all team members.

So the next time you design a curriculum, don’t start designing its content without first documenting general information about the curriculum. The high-level ID information informs the design of the content itself. It’s critical for the team to have a common understanding of the high-level ID to ensure the content the team designs and develops most effectively meets the needs of the organization and learner.

View one comment on “What’s Missing from Your Instructional Design Documentation?

Leave a Reply

Your email address will not be published. Required fields are marked *