I write a lot of courses - in-person courses, video courses, written courses - all of them are different and requiring different things but there are some underlying principles flow through them all. When I trained as a teacher, this was referred to as instructional design. Instructional design is the process of turning learning goals into structured sequences of tasks, content and practice. The aim is to help someone be able to reliably reproduce the skill.

While my first career of teaching mathematics to teenagers is different to teaching technical skills to adults - it’s maybe not as different as you might think.

There is no one accepted “best” instructional design approach. It’s an area of academic study that has produced almost as many models as there are researchers. Rather than share those models, I want to reflect on my process of taking a generating a list of learning goals and turning them into a deliverable course.

Kevin’s ‘Normal’ Process

1. Write the learning objectives

Depending on the circumstance, I might be asked to create a course from nothing. This might be “Introduction to Python” or “Prompt Engineering for Professionals” or “Software Architecture in Practice” or anything in between. I teach Python, JavaScript, TypeScript, Java, Go and PHP (and recently a lot of AI). I work with data engineers, scientists, developers, architects and other professionals. But, whoever and whatever I’m teaching starts with learning objectives.

The central question is: what is the goal of this training? What are the key goals required to make this a reality?

I’ll also spend time doing research - if this is an area I haven’t dealt with much recently, I’ll want see if anything much has changed.

2. Create a general outline

About 75% of the time now, I’ll have an outline from a previous course that I’ve delivered. Armed with the learning objectives, I’ll pull together a general outline. This is the point where I’ll develop an idea of how long the course might be, what the main learning beats are likely to include and what participants will need to be able to do before and after the course.

The focus at this point is around ordering the learning and beginning to craft a journey.

3. Meet with the client and work out what needs to change

The reality though is that the outline is only a jumping of point. All of the courses that I deliver are for folks in real teams with current roles. I, or the company I am subcontracting with, have been approached for a purpose. So, I’ll meet with the people requesting the training and find out more about their need.

Now I want to know what is the “job to be done” by the training. Is this for new staff? Is this a new technology? Why this training now? What do folks already know?

I’ll share my initial outline and we’ll work out together what is missing and what is unnecessary for this engagement.

This type of questioning and exploration is necessary to ensure that what I actually deliver is useful and helpful. My imagined goals are irrelevant. I’m not the person commissioning this training or hoping to benefit from it.

4. Tweak the outline

With the research done, I’ll then update the outline. Referring back to the scoping call notes and making sure that I haven’t missed anything. I’ll share with the client and with sign-off, I can now start to build out the course.

5. From the outline, come up with the modules

Now that I have the outline, I’ll start to chunk the content into managable sections or modules. Each module will have learning objectives but these will be zoomed in from the course level. I want to be clear on what the goals are for this 1-2hr time period rather than the 3-5 days.

6. From the learning objectives map what people know and what they need to know

For each learning objective, I’ll map what people know (which I got from the scoping call) to what they need to know. I’ll make lists of common misconceptions and gotchas, key concepts and understandings and start to gather resources from other deliveries that might be useful. I’ll continue researching - checking blogs, Bluesky, forums and documentation - all the time looking for things that trip people up and examples of where these concepts are well applied.

7. Create examples to help support that journey

With the research done, I’ll start to build out examples. If this course needs slides, I use markdown to create those. I’ll write sample code and think about sequencing the learning - preferring building up examples rather than info dumping.

My delivery style tends to lean heavily on examples - writing code live, building examples, making deliberate errors and asking questions as we go. I’m thinking a lot about making and explaining errors that expose thinking and unacknowledged misconceptions.

8. Create labs to help practice that skill

For the labs I create, I want starter code and solution code. I want meaningful tasks that are similar to real life but that isolate the learning in a particular module. I’ll try to remove any complexity that is unnecessary while making sure that what I leave the participants to engage with is supportive while still being challenging. I’ll also have some extension beats for folks who want to push things a bit further.

9. Create a reference takeaway

The course examples and labs are artefacts that the participants can keep but I also like to prepare a crib-sheet for them to keep after the course. This might be module by module or overall. The aim is to give a tangible asset that they can refer to and spark memories.

10. Deliver and adjust

The course design doesn’t really finish until the course ends. When I start delivering, I meet the people who are in the room. I find out what they actually know and want to know. I update examples, alter labs and try to make these learning experiences as engaging and beneficial as possible. The people who commissioned the course are rarely in the room - I want to help achieve the outcomes that they are paying me for but I need to balance that with the reality that the humans in the room are the ones benefiting from it.

---

I love what I do because I get to help lots of different people. It can be lonely - I parachute in for a few days and then disappear - but I build relationships and hopefully leave folks better equipped and inspired. My ADHD loves that I get to explore different technologies deeply but I do sometimes miss working with colleagues towards a more sustained goal.