Any learning or product administrator can tell you a scary story about a time when glitches, grammar, design, and function served as a foil to their learners. When users are already consumed with other tasks, a digital learning module that functions anything less than flawlessly can seriously reduce motivation. But discovering the right way to do quality assurance can be a time-consuming and often frustrating task. Here at ELM, we’ve had our own share of frustration because the thing about quality assurance is: if your product is flawless, you’re done in a day. Otherwise, you have a time-consuming issue.
In order to correct our process, we went through trial and error. We’ve talked to eLearning QA experts and learned what has to be communicated throughout the process. It’s an ongoing improvement that we’re eager to perfect through leadership, dialogue, intense reviewing, and continuity. Our goal is to make our process faster and more accurate because it’s easy for organizations to miss the mark on their quality assurance by shoehorning it into a process designed for other industries. For digital learning, quality assurance must be the result of layers, proper context, and an amazing team.
If you’re ready for your learning to become quality, tell us about it here.
QA Pain Points
Quality assurance is nothing new in tech. In most cases, QA pros are adept at finding bugs, manipulating software, and prepping for release. But it’s a new ballgame when it comes to digital learning. While some companies try to utilize the same old QA practices, others skip the step altogether.
Hey, we get it. These are some of the common complaints our clients give us when we start talking QA:
QA takes too long. In a perfect world, you could budget a day for QA and get it done. But when you’re dealing with functional programming, there’s the chance that what seems like a minor bug could take hours and even days to fix. This can eat up a tight timeline.
The Fix: Quality assurance deserves a permanent place on the schedule. It shouldn’t be treated as an afterthought, but a regular part of the development process. Give yourself some breathing room and the end product will be better for it.
QA requires too much communication. There’s a lot of back-and-forth in good QA. Everyone has to be on the same page or it could result in disaster. Talking to the client; going to the designer; managing expectations; explaining how changes will impact the module as a whole: all of these conversations take time and must be properly documented.
The Fix: There are tons of tools available to help you better organize communication during the QA process. From the ability to communicate through Articulate to simply using Google Docs to send notes and highlight changes, clients, designers, and the eLearning QA team can work together to keep everyone on the same page and show, explain, and create change.
QA deliverables get mixed up. When you send a storyboard without context, things can get a little muddy during the QA process. Deliverables can be outdated or disjointed, leaving the designer scratching his head over an image or request for change without the right information.
The Fix: Always, always check deliverables against a second source. If you’re sending a script, make sure that it clears with the current storyboard. Want an image changed? Send it with a quick mock-up so the designer understands why. Keep deliverables organized, dated, and in full context.
The QA process lacks continuity and responsibility. When QA is someone else’s problem, it’s tempting for other teams to drop the ball. Who cares if there are a few grammar issues in the copy—QA will fix it. Instead of being used as a tool for a better product, the QA team spends its time fixing other teams’ mistakes.
The Fix: Your QA team doesn’t necessarily need to be a dedicated team. Instead, it can be made up of the very people working on different phases of the project. Loop in the art director to run QA on alignment and visual aspects. Ask the instructional designer to check deliverables for quality and functionality. Shift the burden of QA back on those initially responsible to get the best result before it goes to final QA.
Quality assurance might seem like something that comes at the end of the design process, but it’s more effective (and way easier) if it’s a continuous action that happens throughout. Whether it’s adding enough time to the schedule to run QA or letting each department take on the burden of testing their contributions, QA pain points start to feel much more manageable.
