achievement

Introduction to Gamification Part 7: Rewards and Reward Schedules

by
Intro to Gamification Part 7 Introduction to Gamification Part 7 Rewards and Reward Schedules

In the last chapter, I briefly touched on reward schedules. The most basic way to define reward schedules is that they are a set of rules that define when a reward (or any kind of feedback) is given to the user. I am going to discuss three core types of reward schedule, Random Rewards, Fixed Rewards and Time Dependent. I’m also going to introduce some ideas on how to balance the release of rewards and their perceived value.

Random Rewards

These tough to explain, and really hard to implement well! A random reward is one that the user is not expecting and should probably have no reason to expect. For instance, a badge for their forty-second achievement in a system. There is no obvious reason for it but done with a little Hitch Hikers Guide to the Galaxy humour, it may make someone smile at least!

Random rewards are not the same as gambling, I hasten to add. They should not require the user to “bet” or place anything at stake. These are just little surprises from the system to the user or player, to “surprise and delight” them.

Now, the difficulty is working out when to use them. That is up to you, but overuse leads to the surprise element being diluted.

Fixed Rewards

Fixed rewards are given to users based on predefined actions that they complete. Click “Like” 10 times. Complete 10 modules. First activity, level up, beat the boss level etc. As we will see later, these are the cornerstone of reinforcing progression and achievement in a gamified system but need to be well planned to create a balanced experience. Other examples include rewards for daily logins to a system, bonuses for finding secrets (a bit like Easter eggs), certificates for course completion.

Time-Dependent Rewards

Similar to Fixed Regards, but rather than being triggered they are either triggered by a time-based event or limited by time. For instance, a discount code that is only available on a user’s birthday or Halloween would be considered time-dependent.

The flip side would be time-limited events. So, a reward that could only be gained at a specific time of day (Log in a 12 pm to get the reward), or ones that run out after a set time period (Only available for the next 10 hours). It could also be limited by the number of rewards available, for instance, log in now to get one of ten free gifts.

Reward Density and Perceived Value

However you apply rewards and feedback, especially fixed rewards, you need to have a plan for what you are giving, why you are giving it, how much it is “virtually” worth and when it is going to be given.

If you think back to the User Journey model I proposed in the last chapter, you will remember that the journey can be split into a few different parts. The ones we are interested in now are OnBoarding, Immersion and Mastery.

But first….

FLOW!

So, there is a theory that we talk about in-game and gamification design called Flow Theory1 created by Mihaly Csikszentmihalyi. At a very (very very very) basic level, Flow is a state of optimum engagement and immersion, where the perceived challenge perfectly matches the perceived level of effort. It is a strange experience that feels as though time has no meaning and there is nothing but you and the challenge at hand. Games often achieve this. For our purposes, we are interested in the concept of balancing challenge and skill. If something is too challenging for your current skill level, it becomes frustrating. If it is too easy, you get bored.

Basic Flow Model

No real user journey will be perfectly smooth, no matter how well you design it. From time to time users will feel overwhelmed or bored. Feedback and rewards can help with this, especially early on.

If we think of rewards as tools for reinforcing success, or pats on the back even, then you want to use them to keep the momentum going.

We can layer the User Journey onto Flow, to help us get a picture of how it sits with the concept of Skill vs Challenge.

Reward Density

Early on in their journey, users need more reassurance that they are doing the right thing, they are learning. As their journey progresses, they need less encouragement until eventually, they should not require any at all (they either find an intrinsic motivation to continue or are accepting of the importance of continuing.) Think about teaching a child how to ride a bike. You start off very hands-on, helping every step of the way. Frequent congratulations for relatively small achievements, hugs and cuddles when they bash their knee etc. As the child becomes more adept at riding the bike, they may just require verbal reassurance and praise. Every now and then they will start to struggle or get frustrated, so more praise and cuddles are needed. However, eventually, they forget you are even there as they cycle joyously off into the sunset, whooping and laughing, enjoying their new found skills and freedom!

And so it is with gamification and the use of rewards and feedback. During the first stages, the onboarding, people need more feedback, reassurance that they are on the right track and doing the right thing. In an ideal world, they will start to get immersed in the experience and gradually require fewer and fewer rewards. Once they have “mastered” the skills needed, they should require little to no reinforcement. The reward density decreases over time as they learn the required skills. Perhaps the perceived value of the rewards will increase as the perceived effort increases, but the frequency should decrease.

Ideal Reward Density

Now, as I have said, not all journey will be smooth, so as things become frustrating for a user, we may need to increase the reward density or value, just to give the user that virtual “cuddle” and reassurance that they are doing fine. The other way to use a reward when a user is frustrated is to make sure it has a high perceived value to the user, to really give them the incentive to push on.

Realistic User Journey & Reward Density

 

Perceived Value

A final, but very important note on rewards and feedback, perceived value. The more effort or personal investment a user has to make, the larger the reward should be. If you are just asking them to tick a box, you don’t need to give them a billion points! However, if you want them to write a 10,000-word essay, maybe a billion points would be nice. Set expectations early on by rewarding low skill and effort activities with small value rewards and increase the value of them as more effort is required. If you get the balance of reward value vs perceived effort wrong, you can confuse the user, frustrate them and just plain insult them!

In my view, this is where many people go wrong (not just in gamification), placing too high a value on things that are really meaningless and then not rewarding meaningful actions. I’m not saying doctors and nurses should be paid more than footballers….

Key Learning Points

  1. There are 3 basic reward schedules; Random, Fixed and Time Dependant
  2. Rewards and reinforcement should be relied on less and less over the course of the user’s journey
  3. Reward density should be balanced to skill and challenge to smooth out the flow of the user’s journey
  4. Balance your rewards based on the perceived effort to the user, not just the perceived value to you.

References

  1. Csikszentmihalyi, M. Flow: The psychology of optimal performance. Optimal experience: Psychological studies of flow in consciousness (1990).

 

 

Achievement, Not Just for Achievers!

by

Achievement is a word that, in gamification especially, has several potential meanings and can cause significant confusion. In gamification, it is often associated with things like points and badges. The same can be said for video games these days (think Xbox achievements and Playstation trophies).

To confuse things more, people can be categorised in gamification and video games (using my user types or Bartle’s player types) as achievers. This makes it look a little like only one type of user will actually experience achievement.

This is of course totally incorrect, but understandable at first look. So, what is achievement really and how do we experience it. At its most basic, achievement is the result of doing something successfully that required some level of effort. That is not to say that it has to be difficult#

Let’s look at my four basic user types and explore how they may experience achievement.

Achievers are the easiest to start with. For them an achievement takes effort and skill, they are deliberately seeking obstacles to overcome. For some that may be puzzle solving, for others it may be learning a language. The key is that they are looking to improve themselves in some way and reach mastery. Take a Rubik’s cube. The first achievement for them may be getting one face of the cube complete. At this point, they have mastered a new level of skill.  The point where they achieve mastery would be when they can complete the cube.  However, that may not be the end. Next, they might start working on the speed with which they can finish the cube, and then blindfolded and so on.  Each new level of skill is an achievement, it is a new obstacle that has been overcome and they will get a sense of achievement for each.

Free Spirits are not looking to overcome obvious obstacles like an achiever is, solving a puzzle just for the sake of solving a puzzle is not going to do much for them. They get their sense of achievement from discovery and creation. They want to find the Easter eggs left in a system by a developer with a sense of humour. They want to be the ones to create the most elaborate forms of self expression. These are the sorts of things that will give them a sense of achievement. Solving puzzles and overcoming externally defined obstacles are just a means to an end to allow them to discover and create new things. They are still overcoming obstacles, but they are set by themselves rather than by the system itself. Think of an artist. They have a blank canvas in front of them. There is no need for them to put paint on it, there is no rule saying they have to.  They decide to do it and they decide what they want to do with it. When they are happy with what they have created, they will experience that sense of achievement.

Both of these user types could be said to experience Fiero. This is an Italian word to describe personal triumph (XeoDesign Why We Play Games), achieving something that took great effort and was meaningful to you. This is the moment that you throw your hands up in victory. It is your shout of “Yes” when you finally achieve something. It’s the feeling of beating the highest score in Tetris after 6 months of dedicated play, or finishing your latest masterpiece.  True Fiero is not something most would experience every day!

Philanthropists experience achievement in a different way to the other user types. For them it is about enabling other people to achieve by passing on knowledge or help. They experience joy, satisfaction and pride at knowing they have contributed to another’s success. In Yiddish there is a word to describe a similar feeling, Naches. The true definition of this is pride in the achievements of your children. Over time this has begun to be used to mean taking pride in the achievements of others whom you have helped. You could say that philanthropists greatest sense of achievement would be the feeling naches  they get when someone else experiences fiero because of help or teaching they had from the philanthropist.

With Socialisers, the main goal for them is  to create relationships and maintain relationships. They are not trying to overcome external obstacles like an achiever and they are not trying to achieve personally created goals like a free spirit. They are also not trying to help others achieve anything. For them, achievement comes in the form of a new friend or a quality conversation with an old friend. It is feeling that they are part of a community that values them and their input. When they feel accepted, they feel achievement.

As you can see, everyone experiences achievement; they just may experience it in different ways and for different reasons.  It is really important to understand that every user type can experience every type of achievement, it is just in varying degrees.  An achiever can still feel a sense of pride if someone they helped achieves something new. Just because someone is a free spirit type generally, don’t think they won’t like making friends.

Create gamified systems that support as many types as you can, but if you are limited in time and budget at least make sure you support the most important user type to your needs and you support them extremely well.

Adding badgers would be more gamification than badges.

by

I had a great little article set up for today about forums, chat rooms and gamified social networks. However, with GsummitX London happening today and considering some of the things I am reading of late, I wanted to rant instead. Buckle in 🙂

Badges and points systems. You know them, and loads of you seems to love them. Now, precisely to sound like a broken record, in isolation they don’t work. You can’t make a task more fun, interesting, engaging – whatever noun you wish to use – by JUST adding badges (or badgers as I wrote. Now that would be fun. Mmm give a person a badger everytime they do something right and a honey badger when they get it wrong…). That isn’t gamification. It is like me adding a picture of Mario to a spreadsheet and saying I have created a game.

Badges are best used to recognise an achievement, not be the achievement. Put together with leader boards and social / community elements they can become an enjoyable meta game, but they can not replace intrinsic motivation.

Try harder. Make the task more engagining in its own right. Make completing the task give the player a sense that they have done something. Then recognise that they have done it with a badge. Better still, make it a surprise. That way they will want to do the task and then be have a warm fuzzy feeling that someone thought that what they had done was worthy of note.

Exit mobile version