My Thanks To …

My thanks goes to RSColley (twitter: @burntsugar, http://twitter.com/burntsugar) for prompting this post.

Background

RSColley mentioned that she does not find designing courses as easy as I do, which prompted me wonder how I designed courses. I then realised that I was an unconscious-competent, and I was unhappy about the unconscious bit. RSColley then replied with this delightful tweet: “@philhart do u think you could unpack that knowledge for others without losing *it*?”. Well, yes I could, hence this post. It is my unpacking of what goes on in my grey cell.

Roadmap

Designing a course is in many ways identical to designing information systems, and probably designing a lot of other things as well. It is all about “going from where we are now to where we want to be”. It is form of project management. While the tools of education may differ from the tools of information systems (e.g. curriculum documents are not the same as relational databases), the principles of construction are identical.

Top Down, or Bottom Up?

There was for years a heated debate about whether design should be top-down (start from the overall design first, and then work your way down towards the details) or bottom-up (start with all the details, and then finally assemble them all). Of course, both positions are flawed (as numerous extremely expensive failed projects can attest), and what is needed is a more sophisticated approach. My own approach is more top-down, with continual revisions up-and-down the levels of detail until I have something that I can at least trial and test.

Construction

My approach to constructing something is “you cannot get a higher level thing working until all its foundations are in place”. By way of example, you cannot create a word-processed document until you already some keyboarding skills and an understanding of the language in which you are writing.

Educators are already familiar with the concept of course pre-requisites: these are identical in concept.

The structure of components within a course mirrors the structure between courses: “What do [I] need to know before [I] can go on to the next piece of learning?”. My task then is to fully understand the curriculum document, pull out my own relevant experiences, and remember what I need to know before I could do the more sophisticated work. For example, if I am going to dismantle an engine, I need to know how to use a screw driver and a spanner.

From that point, it becomes almost tedious: arranging all the little bits of knowledge in such a way that each bit has all the necessary preceeding bits in place in my course structure. Then I prepare the delivery and assessment materials around all the bits of knowledge, and check that I have got all the precedents in place while I am doing it. This sometimes results in minor alterations to what is presented when in the course: “Woops, I forgot that they needed to already know about <this> before they could go on to learn about <that>”.

Trialling

Once the magic moment of the first delivery arrives, then is the time that I see how well my course is constructed. There is the inevitable minor mismatch between my expectation of the learners’ responses and their actual responses; in the second run of the course, I have already elliminated 90% of those mismatches, most of the remainder being down to every class being different.

From then on, it is a case of continuous improvement!