goals

Gamified systems need to set specific tasks for users to complete, and then provide them with feedback as they progress towards completing those tasks. A good gamified system then uses other techniques, elements, mechanics etc to support the user towards those goals.

The hard bit is setting good goals, creating good feedback mechanisms and wrapping the experience in something that is engaging! But that is for later.

Let’s start by justifying the statement that gamification can be broadly split into two main headings, starting with goals!

Goals

Games are great at setting goals. They start with one big goal, “save the planet from destruction”. That is a pretty big goal though, so that goal is split into small goals. “Get to the end of the first of ten levels”. That is then split into smaller goals. “Find the magic sword”. This is then further broken down to smaller real-time tasks. “Kill the bad guy, navigate the map” and so on.

We can consider these in the following way.

Quest –> Levels -> Missions -> Task

In our example, the quest is to save the planet. The levels are the stages within which the action is. Collecting the magic sword is a mission. Kill the bad guy is a task. Not all games can be split this neatly, open world and RPG games often don’t have specific levels, just collections of missions (sub-quests) and tasks.  Your quest may be to save the planet, but first, you have a sub-quest to return all of Miss Mable’s chickens. To do that you will need to have 100 experience points, so you will have to complete multiple tasks in the form of killing rats (grinding).

You get the picture, games break up large goals into much smaller and palatable chunks. This is one of the core aims we have in gamification, to make an activity easier to achieve in some way. That may be technically easier or psychologically easier, where the gamification makes the task less of a pain to do.

The core component of goals, in this context, is challenge. Every part of the overall goal completion is a challenge of some type.   Be it grinding to get experience points or fighting the big boss at the end of the level, they are all challenges. The trick is to make sure that the player has the right skill level to meet the challenge as set out in Flow mentioned previously.

If you are interested in diving deeper into the theory of goal setting, check out Goal Setting Theory by Locke and Latham, who set out five considerations that help an individual achieve a goal, Clarity, Challenge, Commitment, Feedback, Task complexity1. It is also worth looking at my Attainable Maintainable goals model.

Feedback

Feedback is both easier to talk about and harder. It is easier because it seems obvious. Feedback is what a system tells someone when they act. If a player succeeds, the system says, “well done, keep going”, if they fail the system says, “bad luck, try again”. But that is just one type of feedback.

Rewards, points, progress bars, badges, leaderboards, certificates, prizes, social status and more are all forms of feedback.

You must decide what feedback types will work best for your solution and what schedule you will use to provide the feedback. Will it be just in time (i.e. as the activity is completed), will it be later as part of a larger report, will it be random feedback like rewards for actions the user may not be expecting rewards for? I will explain reward schedules in more detail later, but it is worth being aware that it does have to be immediate or linear!

Whatever the type of feedback is, it needs to follow a simple rule RIM, Relevant, In-Time, Meaningful.

Relevant

Feedback should make sense, it should have context. If a user gets a quiz question right, the expect to see a tick or a “well done”. They are not expecting a 5-minute fanfare and a million points whilst unicorns sing “You are the king of the world”! Actually, that sounds pretty cool, but you get the idea!

In-Time

Just as feedback needs context, it needs to be delivered at the right time. Again, if a user gets an answer correct, they expect to know about it then and there, or at least at the end of the test. Unless it is an exam, they don’t expect to see the feedback weeks and weeks later! At the same time, a leaderboard does not need to update every 10 seconds if it is measuring large shifts in large sets of data. It could just update once a week at a set time, and users can go and look at it as and when they want.

Meaningful

This is essential, especially when considering rewards as feedback. If it has not meaning it has no value to the user. A badge for clicking a button 100 times will have less value to a user than their degree certificate! That is not to say feedback has to be as epic as that, progress bars as feedback don’t do a great deal, but the feedback is meaningful to the user!

Building and Supporting the System

When building a system, you have to start with what the main goal is, what is it that you need the user to do or achieve. Then you can think about how that goal can be split up into smaller goals. After that, you look at what challenges you can set to get the user closer to each goal.

After that, you consider how you are going to provide feedback to the user so that they understand their progress and achievements. Will points and badges help. Do you need a leaderboard, a progress bar etc? What reward schedules will work best for this situation.

Finally, you can look at how to support this. Is there a narrative or a theme that would fit the system? Do you need to include social mechanics to create a sense of community or competition, avatar building tools, strategy, time pressure etc?

I will go into much more detail about these in time.

Key Learning Points

Read More ...