Documenting skills required for instructional design (ID) work
By Shalin Hai-Jew, Kansas State University
When people think about instructional design skills, they may think about grant-writing; budgeting; project planning; research and writing; photography; illustration; pedagogical design to the target learners; development and testing based on various technologies; troubleshooting; revision. What is less thought about is documentation. This skill is every bit as important as the others, if not more.
What does documentation for an ID project entail? It involves the following:
The needs of various projects will require additional and particular documentation.
Instructional design work may be supported by various models and frameworks that direct where attention goes, how the work is developed, and perhaps, the sequence of work. A common model is the ADDIE Model (or Analyze, Design, Develop, Implement, and Evaluate model). Some suggest that this is only more of a descriptive sequence than a model. The general sequence of the work does generally involve design, development, deployment, and testing. (Table 1)
Table 1: Some Basic Sequences to Instructional Design Work
Sometimes, IDs work alone, and other times, they are part of a larger team (particularly for more complex projects). For an instructional design team, team members need access to particular information and / or resources at various times in the work. The contents have to be available, and they have to be precisely what the individual or group members need. Spending time and energy chasing down resources is time-consuming and frustrating. If something has gone astray, it may take a ripple of emails and messages to find something, if it has not already been deleted. Or perhaps the resource is on someone’s memory device. Or perhaps a former team member has the information, and they are not easy to reach.
In many cases, an ID team has a shared online space, and they have various folders for the various digital and digitized contents. People infer that the most recent file has to be the most up-to-date one. People may edit over each other’s work. And the team may activate to look for a resource if something seems to be missing. This approach is common but fairly haphazard. Or a team member may remove an object instead of just checking it out temporarily before returning it. In these cases, most works may not be clearly named, and the thumbnail view of a file is used to ascertain what the contents are without downloading or opening the file. The team has individual and collective memory, and they have the goodwill to support each other if something has gone astray. There is often a long period of chaos…and then a putting an order to the chaos (usually by the principal investigator and co-PIs in the grant writing phase, by designers in the design phase, developers in the developer phase, and so on.) right before the hard and critical deadlines arrive. This process is organic and generally workable, and people adapt, but a more coherent documentation approach, and perhaps even a light README file, would be more efficient.
For ID documentation to work, what is necessary to collect has to be known. The right object has to be collected. That object has to be findable. The annotations to the object have to be accurate, and often teams prefer to know the time sequence or order to the updates. The documentation should be as comprehensive as possible. If higher security is needed, there are additional aspects to the work. [Some teams may use a semi-structured database to hold their contents, but this requires an understandable naming protocol, clear following of that protocol, agreement on the types of file formats that will be used, and other factors. The team members all have to be conversant in accessing the database and using it in a team-friendly way. Most team members are not professional librarians who can create order out of chaos.]
For the instructional design team, they need access to information, digital resources, digitized resources, and documentation at all phases of their work.
In the Analysis phase, the team is putting together research to inform their proposed work and to design the grant application. They are creating strategic and tactical plans. They are creating and vetting draft documents.
In the Design phase, the team is drafting plans, templates, and learning resources. They are working on the look-and-feel of the resources, the color palette, and the respective applied styles. There is work on file modalities, too. There are often stylebooks created that summarize the standards to which the work will be designed. Such guides are usually consensus-built and evolve over the course of the project.
In the Develop(ment) phase, the team is creating raw contents, like photographs and notes and b-roll. They are creating the respective digital learning objects and other resources. They are refining the work along the way. [For many, there is an alpha and beta testing phase here, where the learning contents are assessed for functionality and legality and language correctness in the alpha phase, and then tested for acceptance by learners and learning efficacy in the beta testing phase. The pilot-testing phase ensures that the learning materials are efficacious.]
In the Implement (or Deploy) phase, the team is uploading the revised learning contents to the respective platforms for deployment.
In the Evaluate (or Test) phase, the team or part of the team evaluates the learning resources based on performance in a live context, with live learners. Revisions are made as needed.
In the prior ADDIE phases, team members use the documented materials for their direct work. What else do the team members use the documented resources for? Broadly speaking, they are used for the following: staying legal in terms of accessing recordings, institutional memory, information (such as for decision making and planning), grant applications, budgeting, grant reports, and other practical work. They help the team see where there are gaps in work. They help the team see how far the work has progressed. Based on the respective roles of the team members, the resources and applications will differ.
Some of the resources may stay fairly raw, such as notes and doodles and drafts, and other elements may be refined in more depth over time, such as the actual learning resources. Given the need to be efficient (and the high costs of human expertise and time), works are only developed to the level of refinement needed and not further. There will be “raw documentation” and “refined documentation.”
The modalities of the documentation may be digital notes (text and visuals and audio and video), meeting recordings, and other modalities.
In some cases, the documentation may be more protected and less accessible to the whole team. The admin leading the work may have access to authorizing documents, contracts, and other materials that may be protected against broader access.
Beyond internal ID team usage, there may be usage outside the team. An outside team may conduct a project post-mortem and need access to the documentation files. Regulatory agencies may have an interest in the evolution of the work. Researchers who are writing works for publication may also need to access the work. Teams that inherit future iterations of the project will need access to the documentation. Perhaps technologists building technologies related to the teaching and learning may also require access.
Too often, documentation of ID projects tends towards informality. There is a shared online space that the ID team has access to, and folders are named haphazardly. Files themselves are named loosely. People update files, sometimes without due care to do so non-destructively. Files fork off into different versions, and it may not be clear which is the most active or correct version at a given time. There may be some direction to develop some content, which ultimately is not used and is then just an undeveloped “stub.”
Shalin Hai-Jew works as an instructional designer / researcher at Kansas State University. Her email is shalin@ksu.edu.
Generally speaking, instructional design refers to purposeful creation of learning experiences and various learning contents. Instructional designers identify what the learning objectives are; the knowledge, skills and abilities (KSAs) needed by the target learners; the necessary learning resources; and practical strategies to attain these ends in the particular learning contexts.
Instructional design skills…including documentation
When people think about instructional design skills, they may think about grant-writing; budgeting; project planning; research and writing; photography; illustration; pedagogical design to the target learners; development and testing based on various technologies; troubleshooting; revision. What is less thought about is documentation. This skill is every bit as important as the others, if not more.
What does documentation for an ID project entail? It involves the following:
- Understanding which records and files are important for the work
- Acquiring the various contents
- Ensuring that no bad information gets into the collection
- Maintaining the various contents accurately, without information loss or corruption
- Ensuring that those who need access have it
- Making the contents as coherently organized as possible
- Ensuring the findability of the various resources
- Enabling reasonable access pre-, during, and post-project
- Guaranteeing a defensible "legal chain of custody" for particular records
- Capturing all raw files to enable revision and recreation of learning contents
- Capturing versions of files as they are evolved and updated
- Setting high standards for the inclusion of materials in the collection
- Certifying that there are quality standards for the contents
- Labeling the contents accurately
- Using informative naming protocols
- And others
The needs of various projects will require additional and particular documentation.
Common ID sequences
Instructional design work may be supported by various models and frameworks that direct where attention goes, how the work is developed, and perhaps, the sequence of work. A common model is the ADDIE Model (or Analyze, Design, Develop, Implement, and Evaluate model). Some suggest that this is only more of a descriptive sequence than a model. The general sequence of the work does generally involve design, development, deployment, and testing. (Table 1)
Analyze | Design | Develop | Implement | Evaluate |
Design | Develop | Deploy | Test | |
Sometimes, IDs work alone, and other times, they are part of a larger team (particularly for more complex projects). For an instructional design team, team members need access to particular information and / or resources at various times in the work. The contents have to be available, and they have to be precisely what the individual or group members need. Spending time and energy chasing down resources is time-consuming and frustrating. If something has gone astray, it may take a ripple of emails and messages to find something, if it has not already been deleted. Or perhaps the resource is on someone’s memory device. Or perhaps a former team member has the information, and they are not easy to reach.
In the real
For ID documentation to work, what is necessary to collect has to be known. The right object has to be collected. That object has to be findable. The annotations to the object have to be accurate, and often teams prefer to know the time sequence or order to the updates. The documentation should be as comprehensive as possible. If higher security is needed, there are additional aspects to the work. [Some teams may use a semi-structured database to hold their contents, but this requires an understandable naming protocol, clear following of that protocol, agreement on the types of file formats that will be used, and other factors. The team members all have to be conversant in accessing the database and using it in a team-friendly way. Most team members are not professional librarians who can create order out of chaos.]
Reasons for accessing shared files and documentation in the various ID work phases
For the instructional design team, they need access to information, digital resources, digitized resources, and documentation at all phases of their work.
In the Analysis phase, the team is putting together research to inform their proposed work and to design the grant application. They are creating strategic and tactical plans. They are creating and vetting draft documents.
In the Design phase, the team is drafting plans, templates, and learning resources. They are working on the look-and-feel of the resources, the color palette, and the respective applied styles. There is work on file modalities, too. There are often stylebooks created that summarize the standards to which the work will be designed. Such guides are usually consensus-built and evolve over the course of the project.
In the Develop(ment) phase, the team is creating raw contents, like photographs and notes and b-roll. They are creating the respective digital learning objects and other resources. They are refining the work along the way. [For many, there is an alpha and beta testing phase here, where the learning contents are assessed for functionality and legality and language correctness in the alpha phase, and then tested for acceptance by learners and learning efficacy in the beta testing phase. The pilot-testing phase ensures that the learning materials are efficacious.]
In the Implement (or Deploy) phase, the team is uploading the revised learning contents to the respective platforms for deployment.
In the Evaluate (or Test) phase, the team or part of the team evaluates the learning resources based on performance in a live context, with live learners. Revisions are made as needed.
In the prior ADDIE phases, team members use the documented materials for their direct work. What else do the team members use the documented resources for? Broadly speaking, they are used for the following: staying legal in terms of accessing recordings, institutional memory, information (such as for decision making and planning), grant applications, budgeting, grant reports, and other practical work. They help the team see where there are gaps in work. They help the team see how far the work has progressed. Based on the respective roles of the team members, the resources and applications will differ.
Content versioning to rawness, to refinement
Some of the resources may stay fairly raw, such as notes and doodles and drafts, and other elements may be refined in more depth over time, such as the actual learning resources. Given the need to be efficient (and the high costs of human expertise and time), works are only developed to the level of refinement needed and not further. There will be “raw documentation” and “refined documentation.”
The modalities of the documentation may be digital notes (text and visuals and audio and video), meeting recordings, and other modalities.
In some cases, the documentation may be more protected and less accessible to the whole team. The admin leading the work may have access to authorizing documents, contracts, and other materials that may be protected against broader access.
Documentation for external usage
Beyond internal ID team usage, there may be usage outside the team. An outside team may conduct a project post-mortem and need access to the documentation files. Regulatory agencies may have an interest in the evolution of the work. Researchers who are writing works for publication may also need to access the work. Teams that inherit future iterations of the project will need access to the documentation. Perhaps technologists building technologies related to the teaching and learning may also require access.
Conclusion
Too often, documentation of ID projects tends towards informality. There is a shared online space that the ID team has access to, and folders are named haphazardly. Files themselves are named loosely. People update files, sometimes without due care to do so non-destructively. Files fork off into different versions, and it may not be clear which is the most active or correct version at a given time. There may be some direction to develop some content, which ultimately is not used and is then just an undeveloped “stub.”
About the Author
Shalin Hai-Jew works as an instructional designer / researcher at Kansas State University. Her email is shalin@ksu.edu.
| Previous page on path | Cover, page 13 of 23 | Next page on path |
Discussion of "Documenting skills required for instructional design (ID) work"
Add your voice to this discussion.
Checking your signed in status ...