How to intentionally leverage game mechanics to motivate users to achieve their goals.
Gamification suffers from vagueness - ask 100 people what they think it means and you get 100 different answers.
We think the best definition of game mechanics is from Gartner - they describe it as “the use of game mechanics and experience design to digitally engage and motivate people to achieve their goals.”
"Gamification is the use of game mechanics and experience design to digitally engage and motivate people to achieve their goals."
An even simpler way of thinking about it is "nonfiction gaming". You’re using the tools of game design to create environments and experiences that people - consumers, internal team members, etc - want to engage with.
Gamification isn’t badges.
When you say gamification, people often immediately associate it with badges, points, and levels. While those are game mechanics you can certainly leverage inside of an experience, that’s a very simplistic definition.
Gamification isn’t the solution to a bad experience.
Part of why gamification has become so popular is that it seems to offer the promise of magically increasing engagement in anything it’s applied to. And while there are many examples of where gamification has been used effectively (which we’ll discuss), it’s not a magic pill.If your product or service is fundamentally flawed, incorporating game mechanics won’t make enough of a difference to turn failure into success. As we often say at Manifold, the best growth hack is a great product.
Gamification does not mean "games."
Gamification borrows from games using tools and techniques to make non-game experiences more game-like. But it does not mean your objective is to create a game where one doesn’t exist.
You can think of gamification on a spectrum. On the one end, you have micro-gamification. This is the use of individual game mechanics in a very tactical fashion to influence a specific metric. You can think of it as a subset of the larger discipline of conversion optimization. Conversion optimization can include elements of gamification, but not all conversion strategies leverage game mechanics.
SproutSocial is leveraging micro-gamification on this registration form to increase motivation.In the middle you have “gamified experiences”, where you are taking either a new or existing application and baking in multiple game mechanics across the entire user journey to create a much more engaging experience.
And on the far end you have full scale games. Here, the entire experience is a game, but it’s still designed to accomplish a business objective of some kind.
All three can be leveraged inside of companies, and all we’ve implemented all three for clients.
The use cases for gamification are vast, but we generally put them into one of three buckets.
The first is to increase top line awareness and engagement with a brand. Game mechanics can incentivize users to participate and increase their exposure to your brand, and to get their friends to do the same.
There are many examples of this in action. Some of our favorite examples:
The second is to improve the onboarding, retention and use of new or existing applications. At Manifold we talk all the time about the customer funnel, which is basically the 5 phases of a customer’s journey with your product. Game mechanics can help improve metrics in the activation, retention, revenue and referral phases.
A few examples:
The third use case is to increase compliance with internal systems and improve sales and support effectiveness. Some examples:
There are other use cases for gamification as well - you can leverage gamification to increase user happiness when interacting with an interface - what we call “delighters”. Easter eggs are an example. Effective use of delights can spur word of mouth, and particularly effective implementations can increase customer satisfaction.
A well thought out gamification model has the following pieces:
Without these elements you either won’t have a complete loop, or your loop won’t be effective, or it will but you won’t know it.
So how do you build the model? The process is very similar to any other development project. Manifold’s process for gamification includes the following steps:
During the first phase, we are seeking to understand three primary things:
Gamification can represent a big waste of time if you’re unclear what it is you’re trying to accomplish. So clarity on business objective is imperative. Each step in the customer funnel has concrete objectives that can be optimized leveraging gamification.
Note that these same principles apply for internal applications - you want to make sure as many team members as possible adopt, and continue use over an extended period of time. Otherwise your investments in new technology initiatives are doomed to fail.
An important note: often the business objective you’re trying to improve is NOT the business objective you’re going to design your gamified experience around. To figure what experience you need to create, it’s essential to dig into the root causes behind a problem instead of simply accepting it as a given.
For example, lets say your CRM tells you sales are sluggish. Rather than implementing a campaign to increase call or meeting volume, you first ask a couple questions and you discover the following:
So we move from an activity issue to a tracking issue to a training issue. And perhaps the best step is to implement and gamify an initiative to increase the number of salespeople taking the training program on the CRM.
Once you’ve identified the business objective, you need to figure out who the players are. In the above example, the obvious answer is your sales team.There are certain situations where you’ll actually have multiple players:
In each of these cases you have multiple types of players, and they’re all important. You’ll want to identify how you can create experiences for each of them that in aggregate help accomplish your business objective.
The last step is understanding the player’s win state. We need to know what they’re trying to do, and what motivates them so the solution we create can compel them to take action.
BJ Fogg runs the Stanford Persuasion Lab. And he has developed a model for what he believes drives behavior change.There are three elements to it - Motivation, Ability and Triggers. If a user is sufficiently motivated to complete an action, it’s sufficiently easy to do, and you show the appropriate trigger at the appropriate time, a user is likely to complete the action you want.
Gamification is about uncovering the behavior change you’re after that accomplishes your business objective and the player’s win state, then using game mechanics to increase a user’s motivation.
Behavior Change = Motivation + Ability + Triggers
So how do you increase their motivation? The goal of your experience should be to make the player feel awesome in some way. Awesome can take several forms.
Inside an internal organization, salespeople are often motivated by success and social rewards. Customer support teams are often motivated by structure and success. Engineers are motivated by looking smart and socially rewarded. Customer personas will have similar leanings. Identifying them and understanding them are essential.
Often companies will try to motivate players by bribing them. While this sounds like an easy way to avoid doing the hard work of understanding their other motivations, it can often backfire.When money is used as an external reward for some activity, the subjects lose intrinsic interest for the activity. The introduction of an extrinsic reward has a permanently altering effect on the intrinsic interest. It does not matter how often or rarely you use an extrinsic reward, just the fact that the reward is introduced changes the game forever.
This mistake is commonly made in loyalty programs or apps with a store of value. Even here, redemption is not the core motivator of loyalty programs. Status is. Foursquare proves this, as does FarmVille. Money goes in. Nothing comes out. In fact, FarmVille did a promotion with 7 Eleven, but it wasn’t redeem your credits for Slurpees. Rather players bought Slurpees in order to get FarmVille credits.
With your objectives defined, your actors named and their motivations uncovered, you’re ready to start identifying the behavior changes that accomplish that mission - the series of actions that will lead to the confluence of your business objectives and the player’s goals. We call this the win state.
There is no silver bullet to gamification. It’s common to hear people starting out in gamification say “Let’s just add some points, and a leaderboard, and the natural desire for people to be at the top of the leaderboard will do the rest.” This is called PBL (points, badges and leaderboards). And it’s wrong.
This is wrong for two reasons. First, there are usually a series of steps that have to take place, or micro behaviors that have to change to lead up to a larger change that accomplishes your business objective. It’s essential to break each step down and identify solutions for each.
Secondly, badges, leaderboards and other gamification elements whose primary motivation is competition actually only appeal to a subset of your players.
Professor Richard Bartle has classified humans as gamers into four types: Killers, Achievers, Explorers and Socializers.
Perhaps the most surprising thing people find when we discuss gamification is the breakdown of each type of player. Many people assume that most players are either Killers or Achievers - that is how most gamification initiatives are designed. But in reality, Killers only make up about 1% of players. The most common player type by a huge margin are Socializers, who represent as much as 80% of the player universe.
These percentages obviously change depending on the type of players you are targeting - it’s likely your target players skew in certain ways. But at a minimum it’s wise to avoid the assumption that they will primarily be motivated by competition. In fact, cooperative games out-ratio in popularity competitive games by a factor of 3:1 according to Jane McGonigal.
Cooperative games out-ratio competitive games in popularity by a factor of 3:1. - Jane McGonigal
In addition to the type of players you’re targeting, it’s important to keep in mind the stage of the experience the user is in. Their goals and expectations are different depending on how long they’ve been a user.
A good game gives players the feeling that they can master it. But as soon as a player masters it, the game cranks the difficulty up. This keeps them in a state of “flow.”Compare that to any non-game. Business applications, complex image manipulation software, CAD programs, and even a simple banking website tend to offer the first time user a lot of complexity. The level of difficulty the system is exposing to the user is far above the skills that the user has at that moment. The system pushes the user into the “frustration zone,” the zone where the user feels overwhelmed and doesn't know where to begin.
On the other hand, when a user becomes very familiar with the system, the system complexity tends to remain at the same level as at the beginning, thus moving the user in the “boredom-zone”.The question that arises for a gamification designer is how to design business applications that balance the skills of the user with the exposed complexity of the system to keep players in the flow state as long as possible.
Lastly, you need to keep in mind the nature of the application itself, and specifically the frequency of the behavior you’re trying to create. There are no right answers here, although certain types of experiences lend themselves to certain frequency patterns:
Gamification has the power to actually increase frequency. But whether you should is a different question - if increased frequency doesn’t accomplish a business objective or a user goal, and simply represents a vanity metric, the answer is probably not.
We’re commonly asked which game mechanics work the best. But as you can probably guess by now, different mechanics work better for different players, with different dispositions, at different stages in an experience. This is why PBL doesn’t work - you need to be more nuanced, and pick the right tools for the job.
Some sample game mechanics are below. Any of these can be effective when used in the right context. But understanding the business objective, player, and the desired win state are imperative first steps.
Given that understanding, how do you decide which game mechanics to use? Different mechanics lend themselves to particular types of actions. The best approach is to ideate around potential mechanics that will suit the given action you’re trying to get players to take, and test each approach through prototyping.
Let’s say you’ve built a question and answer platform, and you’re trying to improve retention (your business objective). The “lightbulb moment” when players truly understand the app and its value might be when they’ve received a fast helpful answer to their first question (your user goal). The series of actions might look something like this:
Let’s also assume that you’ve done the work to understand your player types. You’ve learned most of your new players aren’t killers or achievers, so appealing to status (or implementing game mechanics around that like PBL) might not be the primary mechanism for achieving this win state. However, you have a second set of players -the folks who will answer questions asked by your new players. Your data indicates they skew higher on Achiever.
An ideation process might result in hypotheses like the following:
The hope will be that some combination of these actions creates the most likely scenario to achieve your win state. Armed with your hypotheses, you begin to prototype.
Prototyping gamification isn’t too different from other uses of prototyping. Your goal as always is to identify a viable approach as quickly and cost effectively as possible, using a deliverable that is high enough fidelity to communicate the final implementation with no additional waste.
At Manifold, prototyping consists of a series of steps, in increasing fidelity.
Starting out your goal is to get as many ideas down as possible, as cheaply as possible. And for this purpose it’s hard to be paper and pencil.Sketching allows you to rapidly ideate around potential implementations of each game mechanic for the action in question. Your focus is on quantity, not quality at this point.
There are a variety of exercises you can conduct to make this process more effective, many of which we fold into our Manifold Design Sprint process. Below are some basic guidelines:
Once you’ve identified potential solutions through a collaborative sketching process, we advocate for moving directly to high fidelity designs, forgoing the traditional wire framing process.
Remember the goal of prototyping - you want to get something in the hands of customers with the least amount of waste. While mockups take a bit more time than wireframes do, in our experience wireframes are usually insufficient to communicate your intent to players. They simply don’t understand what wireframes are.Your sketching process likely provides your team with a “good enough” version of a wireframe for the purposes of prototyping - you don’t have to have all the details worked out yet, until you know if you’re directionally on the right track.
At Manifold we often say customer feedback is oxygen. It’s how we keep ourselves honest, how we know whether our solutions are accomplishing their intended objective, and minimizes waste.
Customer feedback is oxygen.
Customer feedback is oxygen.It’s constantly a surprise how rarely organizations show intermediate deliverables to customers. Too many decisions at the tactical level are made inside of conference rooms, with people who are simply too close to the problem and who have baked-in incentives to see the solution work.
Customers, even loyal ones, don’t care about any of that. They will be much more likely to tell you what works and what doesn’t with your implementation, saving you considerable cost that would be incurred by waiting until the solution is live in the world.
Don’t be surprised to find it taking multiple loops to arrive at a viable solution. Humble yourself before engaging in a customer feedback process, and remember that any work spent iterating now is much cheaper than it will be to change later.
The last point relates to specific types of game mechanics. If you do end up implementing some form of a points system or have levels or other forms of social currency, you want to make sure the system has “balance.”
Good point systems have a concept of progressive engagement. They start out easy, giving players points for doing seemingly trivial activities in order to get them engaged and to help them build up an initial store of value (which increases their incentive to continue playing.) As they continue to play, points either become harder to come by, or more likely the number of points required to “level up” become larger. This is one way to keep players in the “flow state” as discussed previously.
You want to make sure your points system doesn’t have any obvious flaws in it. There are several things to look out for:
The way you solve for this is by modeling your system out. You run it through a simulation to see how the decisions you make impact the game over time.
If you have an existing application, you can leverage your historical data to implement such a model. While your game mechanics will (hopefully) alter future behavior, it can still be helpful to see how your system would have rewarded past behavior - for example, seeing how many of your players would have reached certain levels in certain periods of time.
Once you’ve prototyped your solution and have customer validation that your implementation might be on the right track, it’s time to implement version one.
The complexity of your development will depend on the mechanics you decide to use - implementing a progress bar is much easier than implementing a full points system, for example.
What’s essential is to make sure the development team understands the system will likely change over time, and to plan for that change by creating a flexible system.
In order for you to know whether the system works or not, it’s imperative you have two feedback mechanisms in place. The first is an analytics framework.
The most important consideration when evaluating potential analytics solutions is to capture event-based data, not simply transactional data. Transactional data are things like a successful purchase on your commerce site, or a registration for your SaaS app. Event data, on the other hand, are the series of actions the user takes leading up to a transaction - the pages they click on, the links they click, how long they spend on a page, the flow through your app, etc.
The reason this is important should be evident - since your gamification loop is leveraging game mechanics to influence a series of player actions in support of a win state, you need to know whether the actions work. And the actions will be captured most of the time with event based data.
Event-based data doesn’t just happen - it’s important when discussing gamification implementation with your development team that the logging of any event based data relative to the gamification loop be captured as well. Make sure this requirements are incorporated into the larger requirements or sprint documentation.
The second important piece is a qualitative feedback system. Analytics is critical, in that it tells you what happens. But it can often be hard to figure out the why.Rather than creating a bunch of hypotheses for how to improve a step in your loop that isn’t working, you can save considerable time by asking customers directly, using that information to inform your iteration work.
A feedback system doesn’t have to be fancy. In fact, it doesn’t even have to be coded into the app itself. All you need is a mechanism to reach out to players who interacted with your loop, to understand why they took the actions they took.You can do some of this work up front before deploying in the form of user tests. User tests are great at uncovering usability issues (or “ability issues” in the Fogg Persuasion Model) that you can address before deployment. They aren’t accurate representations of reality in that they completely neglect the motivation component. But by conducting them you can eliminate some of the barriers to adoption and get to a successful win state much faster.
One final thing to pay attention to are unintended consequences of the model you developed. While you will have addressed potential balance issues by running the models in the previous step, you might still miss aspects of the loop that make it easier to manipulate.It’s important to assume that players will try to game the system. For example, lets say your app has a review mechanism to suggest vendors to users in a marketplace app. You implement a game mechanic that gives players an extra point in your points system for leaving reviews.
Not long after implementing the loop, you find that you have thousands of reviews. But on closer inspection, the reviews have one word statements like “Great!” or even “I haven’t tried them but I get points for leaving reviews.”
So you try to remedy this by building a rating system for the reviews themselves, giving people points for highly rated reviews. Problem solved!Not so fast. Now you have people giving each other positive ratings on their reviews regardless of their actual content, creating “voting rings.”
Assume the system is going to be gamed, and look out for ways people use the app in unintended ways to exploit a loophole.Remember that you want to avoid upsetting these people, as they are most likely your Achievers or Killers and can represent a disproportionate amount of activity relate to their size. Close the loophole in future iterations, announce the changing of the terms and explain the rationale behind it.
You won’t nail the loop on your first pass - some aspect of it won’t work as well as you intended, or the system will disproportionate reward the wrong behavior. The solution is to get the system up faster, see how people use it, and use the analytics and feedback systems to improve it. Rinse and repeat.
It’s important to not get discouraged, and to make sure the team understands that big wins can take time. We once implemented a referral loop for a client, and it took 7 iterations to nail it. But once we arrived at the solution that worked, they reaped the rewards of more registrations and much less average cost per customer for years.
The sooner you begin working on your loop, the sooner you’ll see results.
If you think you’d like to dip your toes into the gamification space and start trying some things, we’d love to help you make that happen.
Manifold has a full service team that can help you execute from start to finish. We can help identify the players and their motivations, identify the actions necessary to reach the win state, ideate around potential game mechanics to leverage throughout the process, even design and build the solutions. And we love to work inside of an iterative process to maximize the likelihood of success.
Gamification is a lot more involved than most people think. But a well-architected system can dramatically improve retention, referral and virality. To take your system to the next level, don't hesitate to reach out.