Ad Code

Top Tips for Quality Assurance in eLearning


Imagine you are completing an eLearning course. You are on the second screen of the module when you notice that there is a spelling error. You then go to click the back button and nothing happens. Imagine errors like this taking place throughout the whole learning experience. It could get frustrating right? The legitimacy of the learning content may decrease and you could potentially get to a point where you believe it’s not worth even completing the learning; “If the people creating the content couldn’t be bothered, why should I be bothered?”.

This is why Quality Assurance (QA) is integral to an effective eLearning course. It may sound like a simple task though let me tell you, there can be a lot involved, and with that comes a lot of time spent on getting it right. This is why I want to share with you what we have learnt about QA and how you can make your process as effective and efficient as possible when you are developing an eLearning course. The last thing you want is for errors to be picked up when the module has already been released to the world. This can impact your team’s reputation, how seriously people will take your learning content and last but not least result in you having to backtrack and spend more time on a project that was supposedly finalised.

When I first started as an instructional designer I always thought the most time would be spent on developing the initial module; how wrong I was. QA can often take longer than the development and therefore a good QA process is so important to ensure you can meet your project deadlines, not waste any time and deliver a quality final product. For us, if the first round of development takes 40 hours, we can expect QA and implementing QA changes to also take 40 hours. This is because we have multiple rounds of QA (generally 3) and more than one person doing it to ensure we pick up all the improvements required.

Here are our top tips for an efficient QA process:

1. Take a Break/Gain a Fresh Perspective

When you have had your head in a module for a long period of time, from experience I can say that it is easy to miss errors when you complete your own QA at the end of development. We therefore ensure that upon completion of developing a module that we take a break prior to completing a QA on it.

When you have finished development try going for a walk, having a coffee break or chatting to a friend, any activity that takes you out of the headspace that you were in when developing the module. Then we recommend you publish and upload it somewhere external rather than just previewing your course. This will allow you to see how it operates across browsers and once published. You will be surprised by how much more you will pick up with fresh eyes and a new perspective on the module.

2. Have a QA Sidekick

Part of our process is that someone other than the developer completes a QA. It is so important that someone with an entirely new perspective completes the QA as they will see the module as if it is new content. Rather than providing your QA sidekick with the development file, send them a preview of what the end-user would see. They can then record the pick-ups that they find and you can implement their feedback when their QA is complete.

3. Use a QA Checklist

Having a QA checklist is the best way to ensure that all aspects of a module are checked. The person who is completing the QA can cross check each screen against the checklist and therefore ensure that nothing is missed.

Our general QA checklist is used for each of our modules and includes the following generic checks:

Style
- Font size is correct.
- Font type is correct.
- Bullet points are the correct size/style/space from text.

General Layout
- Slide headings are in correct x,y position.

- First paragraph is in correct x,y position.
- All spacing and padding is correct.
- Consistent punctuation.
- Spelling is correct.
- Orphaned words are fixed (one word on a line).
- Alignment of content is correct.

Media/Activities
- Activities tested for range of user input.
- Activities and feedback reset on slide revisit.
- Feedback titles are appropriate.
- Video/web content works.

Navigation
- Total page numbers are set correctly.
- Buttons on screen work as intended.
- Screen starts from its initial state rather than a resumed state (where required).
- The home/chapter/section buttons take you to the right place.

Audio/Narration
- Audio icon is enabled/disabled as required.
- Audio navigation buttons (play/pause) work.
- Audio stops when other media is played.

You may also have certain procedures/design policies that your company follows that you can add to this list. It should also be customised by the developer as they go along specific to the module being developed.

4. User Experience (UX)


Another important part of the QA process is to assess the UX of the module. This takes on a more holistic view (Panagiotis, 2013) and requires you to step into the shoes of your end-user and gain insight into what the experience will be like for them.

For this process it is useful for someone other than the developer/storyboard designer to QA the module. As the developer, you may think that certain interactions make perfect sense as you created them from the beginning, though when someone else has a go, the experience could be completely different.

An example of this is an activity interaction that I created for one of our client’s modules. My colleague who was completing a QA on the module, perceived the interaction completely differently and therefore it didn’t make sense to them. With that feedback in mind I re-created the interaction and made it more user friendly so that the end-user would understand it.

5. Referencing


An important part of eLearning development is that you have referenced where necessary. If you have used a table, image or media item from a certain author then it is important that this is referenced within the module. We use Harvard referencing style unless specified by the client.

6. Accessibility


If your course has accessibility standards, then it is important that you cross-check that the module meets them. If your module needs to meet certain standards (e.g. A, AA or AAA accessibility standards), then you should find the official checklist and check your module against it.

These are some questions related to a course’s accessibility:

- Can you easily navigate through the module using just the keyboard and mouse (Pappas, 2014)?
- Does your module have a ‘help page’ that explains to the learner what each of buttons mean within the module?
- Are the course elements labelled in such a way that the user can easily comprehend what is required of them on each screen?

It is important to note that these questions are only a small part of an extensive list (depending on what level of accessibility is required for your module).

That’s it for our blog on Top Tips for Quality Assurance in eLearning. We hope that these tips add value to your craft and support you in creating great quality modules. If you get the QA process right from the beginning, the process of creating and finalising the module will be much smoother. You can be confident that you are delivering a quality product to your audience and that you won’t be receiving any dreaded phone calls telling you that it doesn’t work or that there are errors. I am sure you have more important things to be doing than constantly fixing projects that have already been released, so give a good QA a go!

                                                         References

Panagiotis, Z. (2013). Assessing User Experiences of eLearning Applications. Retrieved from https://elearningindustry.com/assessing-user-experiences-of-elearning-applications.

Pappas, C. (2014). The Ultimate eLearning Course Design Checklist. Retrieved from https://elearningindustry.com/the-ultimate-elearning-course-design-checklist.

Post a Comment

0 Comments