Better Safe Than Sorry

All instructional designers are familiar with this scenario: We work tirelessly on a learning experience, perfecting the master slides, ensuring pixel-perfect alignment, incorporating theme colors, and integrating narration that sounds just right. And then we send it off to the client, feeling satisfied—only to get an email saying, "I can't get past slide 4 because the Next button isn't working" or "It's not showing up in the learning management system."

Cue the sinking feeling. I know it well. Early in my career, those moments made me wonder whether I was cut out for instructional design work. How can I obsess over design details but overlook something as basic as a navigation button?

I realized then that I needed a robust but simple quality process in my workflow. Most of us begin with quality control, which is the final review that catches and fixes errors before launch. Doing that is important but only half the picture. Quality assurance is the practice you build into the design and development process from start to finish that prevents issues. QC is the check that catches what slipped through QA. You need both for a reliable quality system.

Why quality matters

QA is a promise and commitment to build quality into the entire design process. A QA system enables you to deliver experiences that work well for all stakeholders, not just look good at first glance. I built QA into my design process because I wanted people to regard me as someone who creates not just engaging and accessible learning, but also dependable, error-free experiences.

Beyond professional pride, a good QA system has other benefits.

• Time savings: Reduce last-minute fixes and rework.

• Productivity: Clearer processes free up brain space for creativity.

• Profitability: Efficient workflows mean better margins.

• Client trust: They see you as reliable.

QA is an ongoing process that spans three stages.

Before development: Set the stage for quality

Quality starts before you open your authoring tool. This stage is about creating clarity and structure so that everyone knows what "good" looks like.

Define success. Prior to designing any part of the learning solution, define what quality means and how you'll measure it. What does success look like for the learner, client, and project team?

For the learner, success may mean feeling engaged and being able to apply the knowledge or skills the course introduces. For the client, success often means the learning solution aligns with the organization's goals as well as launches on time and within budget. For the project team, success looks like smooth workflows, clear communication, and minimal rework.

Clarify timelines and expectations. An unambiguous timeline for milestones, drafts, reviews, and feedback that you communicate to everyone involved in the project will prevent questions about due dates. While having a timeline won't prevent missed deadlines, it's more likely to keep people on track.

Create templates and checklists. Start with reusable, standardized assets, where possible, that ensure consistency and save time (two pillars of QA). Consider assets you use most often (such as storyboards and title slides) and create templates you can use for future projects. Checklists for various stages of the development process and for subject matter experts' reviews help to set expectations and ensure consistency across all projects.

Checklists also are a great way to keep track of all the necessary steps. Think about the typical elements you begin when designing a learning experience. Do you use a certain slide dimension? Do you have a template you use in your LMS or authoring tool that you must upload before beginning? I maintain separate lists for accessibility, navigation, visuals, and interactivity.

Know your learner. Keep a learner persona handy and refer to it often. It should act as your compass for design decisions.

Communicate your process. Set up smooth collaboration by letting clients and SMEs know what reviews and approvals you'll need from them.

During development: Build quality into the work

Conducting QA as you're developing a learning solution involves catching your errors before someone else has to. It moves you from being a reactive fixer to a proactive designer.

Get sign-off early and often. Before full development begins, have stakeholders review storyboards and design concepts.

Use checklists for every design phase. They will keep you organized and aligned and ensure you don't accidentally skip any steps.

For example, I have a list of expectations and the typical setup for different project types with my team. So, one of the first things we do when we begin developing an e-learning module in an authoring tool is remove the navigation's Previous button from the first slide and the Next button from the final slide.

We also have an ongoing checklist to refer to when designing and developing a learning experience to make note of navigation. For instance, if we are storyboarding a module, and we want the user to proceed only after they have engaged with the interactivity on a slide, we will make a note on the storyboard to disable or hide the Next button. By doing that in the design stage, we are adding in the QA process before we begin building it in the platform. Adding the note makes it more likely that the developer will remember to remove the button. And because the note is in the storyboard, the designer who reviews the developer's work will also be able to look for the disabled button upon quality check.

Track bugs and notes visibly. Don't let an issue slow down your flow. For instance, if I need to revisit something, I flag it with a large shape that differs from the color scheme, alongside a note. Such a signal is impossible to miss.

Test in context. Check the experience in multiple browsers and devices early, not just at the end. You don't want to discover late in the process that a browser no longer supports your tool.

Align everything to outcomes. Every screen, activity, and quiz should tie back to a learning objective and a measure of success you defined earlier. That way you know the work you are creating is correct and useful.

Check accessibility. Review focus order, alt text, and color contrast as you go. If you wait to do so at the conclusion of the build, you may find out your design must change, which could put you behind schedule.

After development: Reflect, learn, improve

QA is a living system, not a one-time activity. Therefore, the process doesn't end when the course goes live.

Collect feedback. Ask learners, SMEs, and clients what worked and what didn't. You can often get great insight for future projects by simply asking.

Review against your success criteria at the start of the project. Did the experience meet its learning goals according to you? According to all stakeholders?

Revisit after a few months. Fresh eyes will show you what you would do differently next time. For example, you may notice learners consistently skip a particular exercise, suggesting it's too complicated or doesn't work as you intended, or you may find a broken link or a spelling error.

Review and update your checklists. Add recurring issues or wins to keep improving your process.

The role of reviews

Even with QA in place, you still need others to review your work. But not all reviews are created equal.

Clients sometimes say, "I'll just review it at the end to save time." Although that may sound efficient, it rarely works. Inevitably, they come back with design or content edits that change expectations and derail timelines. Early reviews, even short ones, can help to prevent that.

Peer reviews, on the other hand, are most effective as a dedicated step near the end of development—if peers execute them with purpose. In busy teams, peers often rush through reviews or do not complete them, which can result in resentment in a team or missed opportunities for improvement. Note that taking a course as a learner is different than testing a course. Peer designers know how to bypass broken navigation or answer correctly on their first try. But learners won't.

Whenever possible, identify a dedicated quality reviewer to inspect the design thoroughly across all phases of a single project. The individual shouldn't be someone directly tied to the build itself, so they can approach the course with fresh eyes and experience it more like a learner would. Examples include a colleague from another team, a manager, or a learning experience designer who wasn't part of the development (and can suspend their learner experience design knowledge for the review).

Quality checks

A strong review process ensures consistency and reduces issues you overlooked. I typically schedule about two weeks (when possible) at the end of development for thorough testing, discussion, edits, and rechecks.

QC shouldn't just be a "click through and see if it works" task. It's a deliberate, layered process. Each project should have defined reviewers for five categories.

Content. SMEs or content owners should ensure the instructions, examples, and explanations are accurate, clear, and concise.

Design. Examine the layout, visuals, and branding alignment to confirm the visuals and fonts are consistent as well as in accordance with the branding guidelines; and the alignment of objects on a slide is uniform. In addition, ensure consistency among the tone and voice across modules.

Accessibility. Confirm that the course complies with accessibility standards. For example, check the focus order, captions, alt text, keyboard navigation, and color contrasting.

Functionality. Review the interactions, quizzes, links, and navigation logic. For instance, can users intuitively understand what to do? What happens if someone answers a quiz question incorrectly multiple times? Does the navigation work in all aspects, such as moving forward and back on all screens?

Technical. Confirm the experience is compatible with all web browsers; LMS settings are tracking completion; and the file is performing at optimal speeds.

While one person probably can't do all those reviews, you can have a couple of people step in for a different set of eyes. If having more than one reviewer isn't possible, ask your reviewer to go through the course multiple times with a different lens each time.

Providing all reviewers with clear instructions, a checklist, or a review form to guide them through the course will help to keep them focused and not miss any errors.

When reviewing, I use different strategies to stress-test the experience:

• Go through the course backward to see whether each screen makes sense out of context.

• Intentionally answer all questions incorrectly to test branching and remediation.

• Try different devices and browsers for compatibility and quirks of particular platforms.

Developing a quality system that works

Over time, I've created a simple, flexible framework that keeps me consistent across projects. The key is that it works for us—every team's process will look different depending on the team's tools, project types, and size. The important factor is to design something that's intentional and repeatable, not perfect.

When shaping your own QA framework, consider a few guiding questions:

• How will your team share and track updates?

• Where will you store project information so no one has to dig through emails?

• How will you make version control and accountability clear?

Several elements have made a big difference for us.

Project overview document. This is our single source of truth, containing audience information, goals, style guides, and links to tools and documents related to the project.

Fresh files every time. We never repurpose an old project file, because that makes it too easy for stray data or hidden settings to cause issues later.

Consistent naming conventions. Each file includes the project name, module, developer initials, and date (for example, Project_Module1_SW_20260130). That keeps version control clean and transparent.

Visual eyesores. If a designer has left something unfinished, they leave a bold-colored shape on the slide or document with a clear note ("Slide 7: Update drag target alignment—revisit by Feb. 15, 2026"). It's simple (and ugly) but prevents us from forgetting to make fixes.

Collaborative visibility. Using shared drives and quick Slack updates ensures someone else can seamlessly pick up work, if necessary.

Small habits such as those create consistency, which helps everyone on the team. They also turn quality from an abstract idea into a concrete daily practice.

Continuous quality

QA is about caring enough to make the learning experience work seamlessly for the learner and stress-free for your client or manager. Embedding QA into your workflow means you value the process as much as the product. Because if your course arrives on time but doesn't work, no one cares that you met the deadline. However, when you deliver something that's functional, accessible, and polished, you build trust. That trust is what brings clients and collaborators back again and again.