Quality Control Program
📋The Overview
After successfully leading the Fiscal Year Update project, I was promoted to Captain of Quality Control, a newly defined role with one clear directive: build a quality control program from scratch.
There was no existing framework, no checklist, and no standard. Just a real problem and the opportunity to solve it properly.
⚡Quick Facts
Role: Captain of Quality Control, sole program creator
Organization: Learning & Development, remote team
Timeline: Approximately 6 months to full implementation
Team Size: 6 to 8 LXDs going through the QC process
Tools Used: Articulate Storyline, custom QC checklist, LMS tracking, spreadsheet tracking
Outcome: 80% reduction in learner support tickets
Skills:
🔍The Problem
Quality issues were showing up at the worst possible time, after courses were already in the hands of learners. Support tickets were coming in regularly from learners getting stuck or encountering functional problems.
The root causes were varied but consistent:
· inconsistent use of templates
· multiple conflicting masters in Storyline files
· broken triggers
· font and color drift
· incomplete functionality checks before submission
Every ticket represented a learner who couldn’t complete their training and a team member who had to stop and respond. The problem wasn’t effort. It was the absence of a standard.
📊The Research
I didn’t start by designing a program. I started by doing the work.
I was assigned courses after they had already been reviewed by SMEs and leadership, and I went through each one systematically, checking fonts, functionality, colors, completion triggers, sound, masters, and more. As I worked, I kept a running log of everything I was finding and everything I was checking.
From the start, I was also watching the LMS support tickets closely. The volume of tickets about functional course problems gave me a clear baseline. That baseline became my measure of success. If the program was working, those tickets would go down.
What success looked like in my head was a QC review where I found nothing. I never said that out loud because I knew it wasn’t realistic. But it kept my standards high.
🔀The Options
I considered two approaches. A purely reactive model where QC happens at the end and issues get flagged and returned. And a proactive model where I also invested time teaching LXDs what I was looking for so they could catch issues themselves before submission.
The reactive model was faster to implement. The proactive model would take longer upfront but would reduce the burden on QC over time and improve the work at the source.
I chose both.
🗺️The Plan
Start with the foundation.
Fix and standardize the template.
Build the QC checklist from real data, not assumptions.
Use the checklist to run reviews, document findings, and bring that information back to individual LXDs in a way that helped them improve.
Push for accountability standards, including consequences for submitting incomplete work.
🔨The Build
The template. I audited and fixed the existing course template, addressing issues identified during the Fiscal Year Update. I then taught the team about Storyline masters, why they matter, what happens when there are multiple conflicting masters, and how to identify and resolve them.
The checklist. After completing several QC reviews and tracking findings in a spreadsheet, I built a formal QC checklist covering every element I was reviewing: fonts, colors, functionality, completion triggers, sound, masters, and more. I shared it with leadership first, then with the LXD team.
The process. LXDs began using the checklist to review their own work before internal review and again before formal QC submission. I conducted reviews against the same checklist and met individually with LXDs to discuss findings, always pairing critical feedback with genuine recognition of what they did well.
The accountability standard. Multiple masters became an automatic fail, meaning the course was returned for correction before QC could be completed. This was not popular. There were real conversations about profitability and the time QC was adding to the process. I held the line because the data supported it. Catching problems in QC was significantly less costly than catching them after a course was live.
The training. Eventually I trained another person to conduct QC reviews using the checklist as the training framework. The program was no longer dependent on one person. 🔁
🎯The Outcome
Learner support tickets related to functional course problems dropped by 80%.
The issues found during individual QC reviews decreased over time for each LXD, which meant the proactive investment in training and feedback was working. Courses were getting better at the source, not just getting caught at the end.
The checklist became a living document, updated as software changed and standards evolved. It also became the foundation for the LXD Chat program I later championed, where common QC findings were brought to the full team as shared learning opportunities.
💡The Reflection
The hardest part of this project was not building the checklist. It was holding the standard when it was inconvenient. Quality costs something in the short term. The 80% ticket reduction proved it was worth it.
If I did this again I would build the accountability piece in from the start rather than adding it later, because the earlier you set the expectation the less resistance you encounter when you enforce it.
