The perfect process for eLearning design

Developing eLearning is like any other design project. It involves creativity, skill, knowledge, collaboration and a bit of luck! But like all projects, you can’t just hope the magic will happen. It’s vital for a project to succeed, that you have a clearly defined process that everyone involved understands and signs up to.

At Little Man Project we believe in the power of the process so much that we’re on a mission to improve and perfect the one that we use. This happens iteratively as well as during more formal annual reviews. It includes asking our clients for feedback, completing project debriefs, discussing weaknesses and tweaking steps to see if improvements can be made. I’m not saying this to show off (although I’m very proud of the process we have designed) I want to demonstrate how important we believe this process is.

So, what have I learnt and how can this help you? Well, I have some fundamental rules that I’d like to share. I’ll start with some rules for those of you developing eLearning alone or part of a team in your organisation. I’ll then suggest a couple of rules for those of you lucky enough to be working with an external design team to develop eLearning for you. 

Internal teams

Rule 1
Run the development of your eLearning as a project. Have a process. Write it down. Communicate it to everyone involved. Stick to it during the process.  Reflect on its success and evolve it based on the lessons you have learnt. Repeat. OK I could stop there but here’s a bit more detail on what this could look like.

Rule 2
Ensure there are enough review points in your process for you to ask for and apply feedback from all stakeholders.  We use a seven-step, iterative process as follows:

1.     Project kick off meeting (more on that in rule 3). 
2.     Research and design of the module.
3.     Creation and review of a module outline and prototype by the client.
4.     The first version of the module at the alpha stage. 
5.     Based on the feedback, we then move into beta. This can be a good time to run the module past a pilot group who can provide feedback on their learning experience.
6.     The final development phase is gold.
7.     We end the project with a project debrief with the client.

You might not need all these stages but, in my experience, losing any of these steps will probably mean things will go wrong. So try it and see how it goes. As I said in rule 1, you will need to reflect and tweak so you might as well start with the gold standard.

Rule 3
Have a project kick off meeting at the start with all stakeholders involved.  I’d recommend including subject matter experts, the project sponsor, representatives from learning and development (this will probably be you), the project manager (again, this may be you) and potential learners. If the project is for a particular cohort of learners within the organisation then include people in the process that know this group well. For example, if your module is for volunteers make sure you have someone on the project that really understands your volunteers. This meeting must include an overview of the project process (see rule 2), the goal of the learning, learner profiles, assessment requirements and a deep discussion on the topic itself. As a designer this is your opportunity to really understand the topic and the people you are designing for. 

Rule 4
We’ve recently introduced live reviews with project managers into our process. This involves the usual module review by the project team followed by a live review of the module AND feedback. We’ve found this is a much easier process for clients. It allows us to quickly agree the changes required, discuss any ramifications and, perhaps more surprisingly, gather additional feedback that results in greater improvements. It might feel like an extra step, but it has made things easier, faster and better – the aim of all projects! 

Working with an external team

If you’re lucky enough to have a budget to engage an external team to develop your eLearning, make sure you get the most you can from that experience.  Learn how they do things, and use what you’ve learnt to inform your next internal development project. 

Rule 1
Trust their process. They’ve honed and perfected it and it will work. Trying to cut corners or skip steps to save time/money will probably only mean delays.  If you’ve hired them because of the good work they do, trust the process that has got them those results. 

Rule 2
Ensure they are completely transparent about the process from the start, and that you and your project team know what will be required throughout the process. It’s important that everyone understands the process so they can allocate the right amount of time and resources to following it.