A Client’s Guide to the eLearning Review Process

What comes to mind when you hear “review process?” A headache? A thousand papers to pore over? Crying into your coffee? Reviewing your eLearning modules throughout the course of their production shouldn’t feel this way. But without clear roles and expectations, re-work and deadline extensions are definite risks. 

Custom eLearning design and development requires smooth collaboration between you and the development team. The test of this collaboration occurs during each eLearning review cycle.  Here’s a breakdown of roles:

The Client

Your role as eLearning reviewer is to provide specific feedback to the development team at the appropriate times. You’ll want to identify early which of your team members will need to review, including any leadership or executive sponsors that need to sign off. Changes to these roles later will result in rework if additional reviewers are added that provide feedback later or too late in the process. You’ll also want to identify a point person to communicate with the development team. This person will gather feedback from your review team, consolidate it, and communicate it to the point person on the development team.

Development Team

The development team could include a project manager, a graphic designer, instructional designers, developers, and a quality analyst. The project manager will keep the wheels turning by setting up review sessions. The development team will incorporate your collected feedback into the eLearning throughout the development process.

THE ELEARNING REVIEW PROCESS

Kickoff

Once you’ve made the decision to start a project, your team will meet with the eLearning development team to have a kickoff meeting. Here’s where the review process begins. This meeting allows all members from each team get to know each other and align on project objectives. The teams will align on the scope of work, identify goals and expectations, establish creative direction, and finally, review established milestones. These discussion topics are high-level, and follow-up meetings to take a deeper dive into timing for specific deadlines and creative direction can be held following this discussion if needed. The delivery timeline that’s built following the project kickoff will be a focal point for tracking project progress throughout the duration of the project. The timeline will include the who, what and when: who is responsible for each specific action item, and by when they should be completed.

Storyboard

The first deliverable needing review will be the storyboard. The storyboard should depict your content, defining the script, visuals, and interactions. A good rule of thumb is to have 90% of the content defined by the end of the storyboard phase. When presented with the storyboard, you should conduct a thorough review of the content. In general, you’re reviewing whether the content is accurate, whether it covers all topics and points required, and whether it’s being presented in the manner you prefer. Review the overall structure of the course, such as the content flow, logical sequence of topics, and phrasing and terminology. Any content should be provided to the development team at this point. So, if during your review you find something missing, now’s the time for additions.

Prototype

A prototype will be the next deliverable needing review. Often, the prototype will be delivered with the storyboard. The prototype will lay out a few screens of your eLearning in the chosen authoring tool, providing a suggested template upon which all modules will be built. The review at this stage is primarily for creative and visual design. Do you like the look and feel being presented? Are brand standards and guidelines being followed? Some interactions should be included for you to review to give you a flavor of the learner’s experience with the module. Keep in mind that the prototype review is not a content review. Content review is done at storyboard and alpha draft phases.

Alpha Draft

The alpha draft review cycle is your most important review. This is the first programmed draft of the module. At this stage, feedback is crucial. Here is where you should heavily review the content, images, functionality, and interactivity by testing out each responsive feature. This stage should solidify 100% of the course content.

Everyone on your team that requires approval should see the alpha draft, including leadership. Designate a point person to consolidate all feedback to adjudicate conflicting feedback. All feedback should be specific and actionable. Ideally, the question of whether the changes to the eLearning module have been made should be able to be answered with “yes” or “no.” Items to review during the alpha cycle include:

Content:

Validate that all content from the storyboard has been included, and that the training functions as you would like. This is not the time for dramatic content changes.  At this stage, additional content will most likely require a change order, so at this point the content and functionality should be well-defined, and you’re looking at minor details.  Phrasing, verbiage, and grammar are all common tweaks during this stage.

Design:

Here’s where you’ll review the visual design in detail, such as graphics and animation. It’s also important to test navigation and interactivity to see if the user experience needs any improvements. 

Audio:

By this point, there will be a scratch track of any voiceover narration. This scratch track allows you to listen for the timing and synching of the narration or music with on-screen content and for pronunciation of any words and acronyms. If the developers you choose do not provide draft voiceover at the alpha review, you’ll need to give the script an extra-thorough review. Does the wording seem natural? Are the ideas conveyed smoothly? Are there segues between topics to smooth transitions? It might help to read the script aloud to test how it sounds to your ear.

The type of feedback you provide during this alpha review is critical. Generic feedback will result in additional time being spent seeking clarification, so it’s important to be specific and instructional.

Here are three examples:

Unhelpful feedback:  “I don’t like the visuals here.”

Helpful feedback:       “This image isn’t quite right. Let’s use an image of an office employee instead of the image of the nurse here. I think that would be more accurate….”

Unhelpful feedback:  “The typography is a bit off brand here.”

Helpful feedback:       “Let’s stay away from uppercase. For these headers let’s keep it bold, but just stick with Sentence Case.”

Unhelpful feedback:  “I don’t like how this is phrased.”

Helpful feedback:       “Let’s change this phrase to…”

Beta Draft

The main objective of the beta draft review cycle is to validate that the changes from the alpha draft review have been made as you intended. The beta draft of the eLearning should be practically final. If in scope, a professional voice track will be added at this stage and resynched accordingly. Any concerns with pronunciations or sound quality with the audio should be called out at this time.  New change requests should be minimal at this stage.

Final Draft

Once the developers complete any last changes you requested, you’ll be presented with your final deliverable. You should review to be sure all feedback has been incorporated. No additional feedback should be required at this point, unless there is a problem with broken functionality.

 —

There are a number of specific tools to use for eLearning review. An Excel document can work, provided your point person consolidates the team’s edits into one document. Regardless of the tool used, the review process is integral to project success.  By following our proven process and providing feedback that’s specific, instructive, and consolidated, you can rest assured that your project will run smoothly and be a resounding success.