A snapshot of the HCD process

Iterative design cycle

There are many different design models put forward by different proponents, (double diamond, design thinking process, etc). Without going into the detail of these various methodologies, the below is a simple version that we can use to think about how we might try to solve learning and teaching related problems.

Gather information: understanding the problem space and the key parts of the issue

We are naturally doing this constantly as we perform teaching and gauge student engagement and understanding, or as we help people with L&T issues. The design process has some tools for formalising this step a little more, providing ways to help us notice and draw out things we wouldn’t usually see and help us balance out biases that might work their way in to the data.

Interpret: the difference between what people say and what they mean

While you might get information from people it is important to take a moment to look for the core issues behind the ones mentioned. It is drawn out here as a distinct stage in the process because it is a step that is so often missed.

Trial and evaluate: using a prototype and observing what happens

Make a thing and see how it works in practice. Did what you expect change, or something else? Or both? The evaluation in this stage really becomes part of the information gathering stage for the next loop.

Key things to take from the design process:

• It’s inherently scalable – the model can be adjusted to the scale of the problem you have or the capacity you have to address it. ‘Gathering data’ could be just asking students whether they found something useful in class, or it could be a multi-round investigation using different methods to triangulate understanding. Equally, a solution could be a new set of quizzes, or it could be saying something different as part of an instruction to a class. The problem drives the process, you shouldn’t feel the need to do the process ‘just because’. If it doesn’t match with the nature or size of the problem (or scope of the initiative to attend to it) you shouldn’t fee like you need to do that part.
• It’s a feedback loop/spiral – like feedback within teaching itself, the design process is built around a feedback loop. Through identifying, checking and testing, you can continually validate what you have discovered and whether the solution is working to create confidence in each subsequent step. This leads to a cycle of iterative loops and improvements as we respond to the information received at each stage. Ultimately, the size of your iterative loop will depend on the scale and nature of the change. If it’s something that happens each week during a regular class you can alter and test your practices quickly, but if it only happens once a semester (ie, changing how you introduce the course) this may require a bit more documentation so that you can retain your ideas and learnings over this longer period implement it next time round.
• It’s fractal – in each stage you can internally make use of the steps of the whole process to nail down that component. For example, the stage of deciding on a solution can itself be based around the action of prototyping before you go on to test the final chosen one.
• Information is gathered through testing a larger number of imperfect things – process can burn energy and stall when a lot of time is spent in consideration of what solution to try. The faster you fail the sooner you can change direction and the less energy will be wasted. In this way it becomes a cure for paralysis; you have permission to try things and to get it wrong on the path to making something better.