It would be remiss of me to go any further without mentioning some kind of learning design documentation – useful for the elearning developer / designer. A design document sets out what form the game will take, how learning will occur and generally gives you something to work from and refer to. As a serious games’ designer I like to mix the Learning Design with the game design document – how does the game meet the learning objectives – remember this is not just about Gamification, it’s about creating a game to help people learn – a Serious Game: differences between Gamification and Serious Games
You can call it what you like, I tend to call it a Learning Design Document.
If you’re developing a Serious Game for a client they will expect to know what you are going to produce and why you are producing it in that way. They will want to know how your game will meet their learning objectives. It should form something along the lines of:
Learning Design documentation
Describes the idea of the game and proposed game genre, target audience; most compelling features; how it will meet the learning objectives; cost and time to develop. It defines the concept, scope, worthiness and feasibility; sells the idea to your client. You may need a prototype of some kind.
Describes the nuts and bolts of the entire project, with all the details and the method by which each element will be implemented. It describes how learning will occur for each of the learning objectives – in detail. It ensures that what is produced is what you want to produce and what your client wants you to produce.
Project and time-management details; task database; budget spreadsheet; technical specifications; Q/A database. It implements the design document on time and within budget. This may be the job of the project manager (if you have one). But they will require your input on the learning design aspect of the project so you will need to know this in some way or another.
Let’s start by creating learning objectives – useful for the elearning developer / designer – well basically anyone that’s trying to create some kind of learning!. The objectives should be based on the problems the business is going to solve. For example let’s say that the Customer Support Team at Rob’s carpets are making the following common mistakes when logging new customers on the system over the phone:
The full name and address including postcode is not being recorded
A landline and mobile number are not being logged correctly
The ‘new customer’ tick box is not being ticked before saving
How the customer heard about the business is not being added
The details of ‘Rob’s Carpets’ website is not being given to customers over the phone
So our learning objectives should be something along the lines of:
By the end of this course you should be able to:
Enter the customer’s full name and address including postcode
Enter the customer’s landline and mobile telephone numbers
Ensure that the customer is logged as a ‘new customer’ before saving
Log how the customer heard about the business
Ensure that the details of ‘Rob’s Carpets’ website is given to customers over the phone
You can make your objectives ‘SMART’ objectives but I’m going to keep them ‘unsmart’ as not to over complicate the design at this stage. If you want to learn more about creating ‘SMART’ objectives and also download a handy PDF, try this: Creating SMART objectives
In the next post I’ll explain how the objectives will form the basis of the quest game.
As an elearning developer / designer, It is important to distinguish between these two types of motivation:
extrinsic motivation – where you are engaged because of a goal or reward;
and intrinsic motivation – where the activity itself is fun and exciting, with or without a reward.
Extrinsic motivation has it’s place in gamification and learning however the goal of any designer should be to tap into the intrinsic motivation – it lasts longer and ultimately is more productive for the designer, the game and the learning.
Week 1 will be our ‘defining week’ for the elearning developer to begin work. We will identify a problem that we need to solve with some kind of elearning game. We will also define the motivation of the ‘players’ as without motivation they will not play and consequently they will not learn. And finally we will decide on the two main game elements 1) the fun aspect 2) how learning will occur as a result of playing the game.
bespoke elearning problem
So let’s invent a potential bespoke elearning problem and then see how we can develop a game using Storyline to resolve it…
Problem: Staff in a business (let’s call it Rob’s Carpets) have recently received training on a new system that allows them to log how new customers made first contact with the business. However many of the staff are making mistakes and need some kind of refresher training. So to provide the extra training the staff need, we will create a game. This game will provide the refresher training in order to reduce the mistakes made.
Let’s give the game a name: Customer Quest (it’s probably a good idea to keep the name in the positive sphere – I wouldn’t recommend for example calling it – ‘Stop making bloody mistakes!’. The trick is to train staff without them realising it) Fun element: The game will be created as a simple quest type game. Learning element: The game will introduce questions and feedback which will help the ‘players’ to learn as they progress through the quest.
Gamification, wow! – where has this been hiding for the learning designer for the past twenty years? Well, like me, if you’re an elearning developer, you’re probably thinking it hasn’t – now it just has a name (although I get the impression that many gamification designers don’t actually like the term ‘Gamification’ and prefer alternatives such as ‘Applied game design’ or ‘Motivational design’ or many more alternatives). My personal preference is the one devised by Amy Jo Kim (founder and CEO of the game design consultancy ShuffleBrain – http://www.shufflebrain.com/) – ‘applied game design’ and so that is what I will use from this point forward.
Note: However I am also a massive fan of the work of Yu-kai Chou (http://www.yukaichou.com/). His alternative to the term Gamification is Human-Focused Design. Again this type of design has been around for a long time (student-centred design). Yu-kai Chou argued that the reason we call this design principle Gamification is that the gaming industry was the first to master Human-Focused design. I think he has a point!
The name however is incidental and this series of blogs will concentrate on a practical approach to applied game design. In essence I will design a serious game (one that is used for learning and not just for fun) using Articulate Storyline. I’ll start from the beginning, define the pedagogy and learning design and then explain how to build it. Hopefully you will find it useful and can incorporate some of the approaches I use into your own projects. Feel free to offer suggestions and even correct me if I don’t get it quite right. No-one’s perfect!