When you are creating a piece of learning, you want to be confident that you are building a sound learning experience, with the end result being a quality piece of learning that you can be proud of. As much as we would like it to, this doesn’t happen by magic. It happens through our time, efforts and hard work, often supported by our equally hardworking colleagues.
When I built my first piece of eLearning, I thought I was invincible, and my work was brilliant. The idea that I might have made an error never entered my head. So, I worked away at building my module and proudly published it and sent it to my SME for review.
Their review and feedback was brutal. I had mistakes in my build, inconsistencies in my slides, but most of all I had the content wrong. The outcome? Delete my efforts and start all over again!
In the years since that first disaster, the content development process I follow has evolved and improved as I learn with every project I take on. And part of that process has been to build in effective eLearning QA and testing; from planning and design through to execution.
So when do we test our learning?
I firmly believe that we should test at every step of our content development process. It may seem like it is adding a lot of work to the process, but by adding the effort in from the start, we save a lot of pain and rework later. Let me explain:
Start from the kick off
For us here at Cursim, every new project starts with a kick off meeting with the client. We typically discuss the project as an overall, from branding through to content, expected duration, and the clients hopes and wants.
So I take the opportunity to test my understanding after the meeting. If I summarise all of the key points as I have understood them, and share this with the project group, I can confirm I have understood correctly and am on the right path. It can also highlight anything I have misunderstood, and can pinpoint things that have changed since the meeting.
Come up with a plan
Don’t dive straight into designing your course content. Review your source materials and come up with a plan of what you want to cover, and what you think the course structure looks like. I like to use an organogram to show my structure; it helps me clarify my thinking on what the course looks like. I test my plan by sharing it with the client, and discussing my approach. This gives me opportunity to fine tune the structure before I delve into designing the content.
Work on the design
Produce a storyboard of your content. There are so many ways you can do a storyboard to outline your content. I like to keep it simple and use PowerPoint. This gives me a great way to plan my content slide by slide, including on screen text, audio text, visuals and graphics. I can easily move slides around, duplicate them, hide them, change how they look, and play with my content in a quick and simple way. Once I am done with my design I can spell check it and read it through from end to end to ensure it flows and makes sense from one slide to the next. I like to get a peer review as well from one of my colleagues; another set of eyes can spot issues and inconsistencies that you may miss because you are so close to the content.
But the best part is, that I can use this PowerPoint storyboard to share my design with my client. We are designing a visual medium for the client, so I want to show them what their module will look like. The client can review the content design, and add comments about issues, errors, corrections, additions and deletions – all straight into the storyboard; no potential for misunderstanding. So I get a whole new level of QA at this stage from the client and I can move forward; confident that we have the right content and the right look and feel for the module.
I don’t build a thing until I have a storyboard the client has approved and signed off. I only want to build the content once, and waiting for approved content can save days of reworking and rebuilding content because the design has changed.
When we get to the build stage, this is where our testing and QA gets much more detailed and involved. I start by checking that the content has been built as per my storyboard, no slides missing, no incorrect text or visuals. Then I publish the content, and check it in its final format.
My typical checklist of questions include:
- Have all of the slides been built? In the correct order? With nothing missing?
- Are the visuals correct for the slide? Are they crisp and clear?
- Is the font consistent throughout? Size? Colour? Line spacing? Alignment?
- Do the slides/elements/animations work as I was expecting?
- Any spelling or grammar issues?
- Is each slide laid out correctly and consistently? Nothing overlapping the edge of a graphic, or falling off the edge of the screen?
- Does the menu work correctly? Are there any incorrect links?
- Can I easily work through the module from start to finish?
- Can I effectively navigate backwards and forwards through the content?
- Does the audio play correctly? Is it synced with the animation to best effect?
- What happens if I get a question wrong? And similarly what happens if I get a question right?
- If we have any, do all of the assessments work? Run through all correct answers – are the results correct? Run through incorrect answers as well – check error messages appear correctly? Can I retake the assessment?
- Am I happy with how the entire course works?
When I have tested, and run through everything and ironed out any glitches and issues; it’s time to send it to the client for their review and comments. This is the nail biting part!
But after all of these years, I know that if I QA my work at every stage, and pick up every minor fault that I can, from a next button not working to a missing full stop, then this review will be painless. We get to have a great conversation about what the client likes, and where they would like to see some tweaks.
So what have I learned? Attention to detail is everything, and cutting a QA corner never saves you time…