Michael Wu, Ph.D. is Lithium's Principal Scientist of Analytics, digging into the complex dynamics of social interaction and group behavior in online communities and social networks.
Michael was voted a 2010 Influential Leader by CRM Magazine for his work on predictive social analytics and its application to Social CRM.He's a regular blogger on the Lithosphere's Building Community blog and previously wrote in the Analytic Science blog. You can follow him on Twitter at mich8elwu.
Welcome back! It’s been almost three weeks since I last blogged and I have been very busy traveling. Last week was lecturing for the Rotman Executive CRM program at the University of Toronto. And the week before that, I was invited to a meeting for the Points of Light Institute at Senator Nunn’s residence at St. Simons Island to discuss technology for civic engagement and social mobilization. Finally, I have also been invited to participate in a mobile commerce panel at the Social Loco Conference this Thursday (Cinco de Mayo). This article was mostly written while I was on planes jetting this way and that, so hopefully the writing isn’t too rough! :-)
Alright, let’s dig in. While I am still quite new to the CRM and social CRM space, I have learned, through interactions with my CRM friends, that one of the many challenges facing Social CRM will be adoption. In fact, traditional enterprise software (e.g. sales force automation) often experiences a very steep learning curve and is not well adopted within the enterprise. Even if it is adopted, people often hate to use it. Employees only use it because their job requires it. On the contrary, people love to play video games. They would even pay money to play. Yet, a video game is just another piece of software.
What is it about video games that make them so desirable and addictive? I covered the answers to this question in the early articles of this mini-series. If you missed them, I definitely recommend reviewing the following posts before proceeding:
Today we will use what we’ve learned to address a more specific question: can we make enterprise software more fun and entertaining through gamification? The easy part of the answer is “Yes.” The hard part is “How?”
Why is Enterprise Software no Fun?
Before I address the question of how, perhaps we should ask why wasn’t enterprise software gamified in the first place. With our current understanding of gamification using Fogg’s behavior model, it seems like a “no brainer” that all enterprise software should be gamified.
Gamified software not only drives adoption, it often leads to increased usage through Skinnerian operant conditioning. Users also learn to use the software better through increased usage and encouragement to explore new functionalities. The social gaming dynamics can foster team work, collaboration, and even a healthy level of competition within your organization. The result is ultimately a huge boost in productivity.
If gamification has so many benefits, why wasn’t enterprise software gamified? I hate to speculate, but I suspect that one of the reasons is that fun was never a requirement for enterprise software. Early software architects simply did not understand that fun and adoption go hand in hand. If you make it fun, people will use it. If you truly believe enterprise software can boost productivity (if used properly), then fun becomes a requirement for productivity, since adoption is clearly a prerequisite for realizing the productivity gain from using the software.
It is ironic that enterprise software and the video game industry do not collaborate more. If they had, enterprises could reach a new level of productivity never seen before. So if you ever get involved in software design, make sure it’s entertaining! Never underestimate the power of fun.
Turning Enterprise Software into a Game?
Although there are many ways to gamify enterprise software by incorporating one game dynamic after another, I will propose a more radical idea that utilizes game design to its full extent. Rather than bolting game dynamics onto the existing software, we should re-design the entire software as a game. This essentially turns the entire software into a gaming platform.
What does this mean? It means the software must have the capability to record every single action that every user took, like a complex role-playing game (RPG) that keeps a complete history of every player’s quest. Once, we have this tracking capability is in place, all the game dynamics are easy to implement. Each user will have a profile of their software usage history and achievement. Moreover, they don’t need to actively maintain it. The profiles are updated automatically based on how they use the software.
In the following sections, I will outline some of the most basic principles to guide the process for gamifying enterprise software. And I’ll leave the rest to your creativity.
How to Gamify Enterprise Software?
Enterprise software usually has many complex workflows and functions that most people often do not use. Just looking at the sheer number of menu items and toolbar buttons is often enough to demotivate people from using the software.
This is where a bit of Cascade-Information Theory could help. Why show all the functions that people are not ready to use? Only the most common functions that everyone uses on a weekly basis should be shown by default. The rest of the functions should be hidden, but easily searchable and findable if needed. And once a user uses one of these hidden functions, it becomes visible to him thereafter.
Since all usages are carefully tracked, we can easily identify people who use the software well and reward them with the proper status and recognition. The number of ways in which a user can use the software is, well, virtually infinite, so I can’t possibly list them all here. However, I will discuss three important classes of usage behavior.
Discovery: Users who are among the first to utilize certain rarely-used function and completes a task with it
Completion: Users who are among the first to complete using a set of related functions for a complex task
Proficiency: Users who use certain rarely-used function frequently and completes many tasks with it
Proficiency is actually two categories, because there are two ways to measure a user’s proficiency in software usage.
3a. Quantity: The total number of times the user uses certain functionality of the software
3b. Velocity: The frequency (or rate) of usage of certain function
I want to emphasize that these usage behaviors happen to incentivize three of the gaming personalities described by Richard Bartle. Explorers, achievers and killers are all motivated by completion to a certain extent. More specifically,
Explorers have a clear inclination towards discovery
Achievers are definitely motivated by the accumulation of experience points, status and ranks associated with their proficient use of the software
It may seem like that we are almost done, since we can motivate three of the four gaming persona. However, approximately 80% of the populations are Socializers. Explorers, achievers and killers make up only about 20% of the population. So how can we make the software engaging for the socializers? The solution is simple. We just have to infuse social features into the software.
Socializers get their name because they like to socialize in a collaborative non-confrontational environment. So when users search for a particular feature/function, show them others who have used that function. That is, who discovered that function first in the organization; who used it the most number of times, who used it recently with the highest velocity, and most importantly, which of their peers have also used this function. Finally, the software must enable ease of communication with others, so people can ask for tips and advice from people who have used that function.
Much enterprise software experiences poor adoption because fun was never part of the design requirement. However, as we now know, fun can be crucial to productivity, because it’s the key to drive mass adoption, which kicks off the network effect that benefits everyone. The foundation for any effective gamification approach is to keep careful and detailed records of all usage of all functions by every user. This enables the system to reward users in three different ways.
Proficiency: which includes both the absolute Quantity and the relative Velocity
Although this covers three out of the four types of gaming persona (i.e. explorers, achievers, and killers), we must not forget that socializers is still the largest group making up roughly 80% of the population. To keep the socializers engaged, we must infuse the enterprise software with social features that enables their users to socialize.
Alright, this short post is probably an over simplification of what can be done to fully gamify an enterprise software. But it is a start, and it points out some of the basic ingredients upon which you can expand upon. There are certainly many game mechanics/dynamics that we can use to drive a specific kind of user behavior. I can’t possibly cover all of them without turning this into a book. So let’s make this an open discussion. Your creativity and voice are always welcome.
Stay tuned for the next and probably the last post on this mini-series on gamification.