How to review eLearning without derailing your project

Most people have never been told how to review an eLearning module. They're just handed a link and expected to know what to do with it.

What exactly are you supposed to be looking for? How detailed does the feedback need to be? And what happens when someone new jumps in to review at the last minute with a whole list of comments? (We call that person Ronny. Every project has one!)

The good news is that with the right structure in place, reviewing an eLearning module doesn't need to be stressful - for you or your eLearning partner. Here's how we make it work at Learnopolis.

We tell you what to look for at each stage Different stages of the project call for different kinds of feedback. Early on, we want to know if the structure and flow feels right. Later, it's about whether the content is accurate and complete. By the time you're reviewing the built module, we're checking that everything works as it should - not reopening decisions that were made at the storyboard stage.

Knowing what's in scope at each point means your feedback is focused, useful, and doesn't send the project backwards.

We ask you to consolidate before we act When a module goes out for review, we ask that everyone who needs to see it goes through it before we start making changes. That means you (as the decision maker) get to decide which comments you want actioned - filtering out the contradictions, the late opinions, and Ronny's suggestion that the module should basically just be the existing 47-slide PowerPoint, but with a Next button.

It sounds like a small thing. It makes a huge difference.

We're transparent about where everything stands I came across a brilliant video from Marie-Jo Leroux on handling client feedback, and she introduced a coding system for review comments that we adopted straight away (we’re always looking to improve, and it would be daft to ignore good advice!).

Every comment gets a clear status: we're on it, we need more information, we can't reproduce the issue, or not a defect. That last code is particularly useful when Ronny reappears at the eleventh hour with strong opinions about something that was signed off three weeks ago.

It means you always know exactly where every piece of feedback stands, without having to chase us for updates.

A structured review process isn't about being rigid. It's about protecting the project, and your time, so that the final module is everything it needs to be.

Have you been part of a review process that worked really well, or one that really didn't? I'd love to hear what made the difference.

Nicola