Quality Assurance Strategies in Instructional Design
My first encounter with quality assurance was in high school. We spent an entire school year learning how to write a research paper. We learned how to find a high quality source, cite it when we used it, and cite it in a way you could find it at the end of the paper. The idea was, “If you’re using someone else’s knowledge in your work, give them credit, and get it right.”
As an instructional. designer my whole job is using someone else’s knowledge in my work. I’ve developed a QA process to make sure I give them credit and I’m getting it right. It’s a cadence of “I build a thing, they give me feedback, I build it better.” But I was recently asked to develop a QA process for a professional development team. How do I take a QA process that works for me and make it work for a team?
I am not a SCRUM leader and this team does not have a SCRUM ecosystem. It is does not have a build phase, a test phase, and a team of QA specialists. It is a team of dedicated professional development trainers who want to collaboratively make exceptional content. So what do you do?
Well, the team makes four types of learning assets (presentations, documents, handouts, and forms.) Step One is deciding what a quality asset means. What does a presentation deck need to have to meet the standards that the team wants to meet? We make a checklist that has four categories: accessibility, instructional design, brand fidelity, and subject matter verification. Accessibility: does the color contrast of the text meet Web Content Accessibility Guidelines? Instructional Design: does the presentation have an achievable, measurable objective? Do we have a measuring mechanism in place to see if we are succeeding?
Once the checklists are built, we need to build a manual that tells you how to do a thing like check the color contrast to make sure it meets WCAG guidelines. Support documentation needs to be there, but there needs to be a distinction between a checklist and a support document.
And then we test. That’s where we are now. We have a robust support manual and 4 ambitious QA checklists. I have an idea for a feedback cadence and final check process, and we’re going to try it out and see what works.