Sep 12

More On “Drive,” Mastery, Autonomy, Gamification, and All That

Board games

A mess o’ games (photo by Eric Mallinson, CC 2.0 license)

Comments Are Good!

I was chuffed to get a long comment from Kathy Sierra on my last blog post, about how gamification of enterprise applications aligns with Dan Pink’s “Motivation 3.0” as he describes it in his book Drive. I’ve been a big fan of Kathy’s for many years, since I first discovered her “Creating Passionate Users” blog, and then listened to her many talks that are available via IT Conversations and other places on the web. (An annotated bibliography of Kathy’s good stuff is below.)

Kathy took some exception to my admittedly simplified descriptions of the components of Motivation 3.0 – mastery, autonomy, and purpose. And some of her points were welcome clarifications to what I sketched in my post.

Any attempt to use external regulation for anything that might EVER be intrinsically motivating is a dark path, and one I would strongly reconsider if I were looking into enterprise gamification. Gamification claims to be taking “what is good about games”, but it is actually doing the opposite. What is good about games does NOT lie in the mechanics (look at the oldest game — one still extremely popular throughout much of the world — the game of Go. It has all the essential ingredients for Motivation 3.0, and almost none of the surface mechanics), but rather in the core experience which IS intrinsic motivation: it feels good to do it for its own sake.

First of all, I completely agree with her that the fundamental challenge we have in gamification of enterprise applications is that adding extrinsic rewards to a knowledge-based activity can have the extremely counter-intuitive effect of reducing the intrinsic motivation to do that activity. As I’ve said over and over in this series of posts about gamifying enterprise applications, I’m assuming that the users are already well motivated, intrinsically, to use the apps and to do a good job. So gamifying them is not about increasing their motivation, but rather about achieving other important goals that enterprise applications (indeed, most other applications) do not do well, but which gamification can do a good job of.

So let’s rephrase what our goals for enterprise gamification are. There are three problems:

  • Getting attention – that is, competing against all the other distractions, whether they are hallway conversations or Facebook, or doing expense reports
  • Getting feedback, especially enabling feedback
  • Making the interactions more fun, engaging, satisfying, pleasant

Which summarize to one big goal, in Kathy’s own terms:

  • Enabling them to “kick ass” at their work

As Kathy notes in her comment:

Games often make excellent use of feedback, but it is the feedback in games, not that they are games, that makes them so good at creating higher skills. Feedback is an absolutely essential element for developing competence (and ultimately mastery), as virtually all learning and improvement happens as a result of high-quality, low-latency feedback.

And that’s the key component of what I’m suggesting we learn from good games in our gamification of enterprise applications.

Again, I’m not trying to motivate people to do a good job (they are already motivated to do that, and I don’t want to mess with that intrinsic motivation), but I’m trying to:

  • Help them make the decision to leap into the work, which is the only way you get into flow
  • Help them get into flow by removing obstacles and making the experience more engaging
  • Help them know when they are doing a good job or have done a good job, so they can be constantly improving – think of this as supporting “deliberate practice.”
  • Help them have a better time doing the thing that they already want to do – this is like giving a musician a better instrument, or a photographer a better camera – they can’t always take advantage of all the improvements, but it’s just easier to learn to play guitar, for example, on a good instrument that’s well set up than on a cheap instrument that’s always going out of tune and has terrible action.

Work is always hard, or it should be, but it should be just as hard as you can actually accomplish, and not easier, and not harder, in order to make maximum progress.

Heading Toward A New Categorization of Gamification

As I’ve pondered this conversation with Kathy, and what I’ve learned in Kevin Werbach’s (@kwerb) Coursera course on gamification, I’ve realized there really are two threads or rivers of gamification. I’m calling them, for now “coercive” and “encouraging” – I’m sure there are better words, especially for the latter type. Specifically, I’m partitioning these as follows:

  • There’s the set of things that we don’t want to do but we need to do (e.g., fitness and new habits fall into this category for some) or that someone wants us to do (e.g., visiting a marketing website, slow down on the road). That’s the realm of coercive gamification.
  • Then there’s the set of things that we want to do, and we’re motivated to do, but we sometimes need some help in doing them as well as we’d like, or in getting started, or in keeping going, or in truly getting into flow or getting engaged, or in knowing how well we’re doing, or what we need to do in order to get better. This is the domain of “encouraging” gamification.

It’s very possible that this distinction has been made already, and I’m just rediscovering an already well-known map, that even has correct place names. If so, I’m sure I’ll hear about it in Werbach’s course in the next few weeks!

In any case, I expect to spend a lot more words on these concepts in future posts.

Also, I just found another recent post from Kathy on a very similar topic, responding to a post by Larry Ferlazzo on gamification in education. Similar concerns, and very apropos of this discussion.

My Favorite Kathy Sierra Stuff

Now, as I mentioned, I’ve been a big Kathy Sierra fan for a long time, and I’m always happy to have a chance to share her awesomeness with the rest of the world. Here are some of my favorites from her:

Of course, there’s her blog, Creating Passionate Users, which is an archive at this point, but I highly useful archive. Some of my favorite posts are:

Her talks (most of these are audio only, but some videos) – all worth the time spent watching/listening and learning:

Comments Are Open!

OK, I’m looking forward to hearing about how far off base I am – let ‘er rip! (In the comments.)

Sep 12

The “Drive” To Gamification: Motivation 3.0 and Game Mechanics

Dan Pink's Excellent Book "Drive"

Dan Pink's Excellent Book "Drive"

Gamification, especially as it applies to enterprise applications, is all about engagement, and quality, and helping people achieve their goals. Or, to put it another way, it’s about motivation. There’s another approach to thinking about motivation, especially of knowledge workers (i.e., those who work with enterprise applications), and that’s as exemplified in Daniel Pink‘s awesome book Drive: The Surprising Truth About What Motivates Us. For the purposes of this discussion, we can summarize Pink’s main point briefly as follows:

We are in the age of “Motivation 3.0,” and motivation primarily is driven by three key dimensions – mastery, autonomy, and purpose. That is, if you want people to be motivated to do their work, they have to have or be working toward a sense of mastery. They have to feel they have some amount of control (or autonomy) over what they do. And the work they do has to be aligned with a higher purpose, it can’t just be “because.”

How does this idea of Motivation 3.0 apply to or intersect with gamification? Gamification is the solution to a lot of problems that especially enterprise software faces. In particular, gamification is intimately related to surfacing the components of Motivation 3.0 – mastery, autonomy, and purpose.

  • Mastery: Games are the best examples we have of reporting on a person’s mastery of something. Nothing else is as good. PhD dissertations are not that good, as we all know. High stakes testing is terrible. And so on. Games have this all over the place, with their points, levels, leaderboards, badges, etc.
  • Autonomy: One of the key components of autonomy is the “ability to get into a flow state.” And games, again, are among the best examples of this, and they certainly are the example of getting people into flow state more easily than any other activity. Even musicians have a harder time getting into flow than gamers do. Millions of gamers every day have to be dragged from their game consoles or computers after hours of playing because of the appeal of the flow that’s generated.
  • Purpose: One hopes in general that most peoples’ jobs provide them with a certain modicum of purpose, and that’s a fundamental assumption I make about gamification of enterprise apps – we’re not trying to solve the “purpose” part of the equation. But the work itself typically doesn’t help a person understand if what they’re doing is helping drive toward achieving the purpose. So, there’s a high level purpose, and we often have that in our job. But our day to day work may or may not be helping us achieve it. Games, again, are amongst the best tools we have for understanding if we are achieving our purposes. In games, of course, the purpose is much less compelling than a real life purpose (“Save The Princess!”) but because the linkage to making progress on the purpose is so strong, it’s enough to keep people engaged. Just think of the power we could have if the day to day, hour to hour work of a person could be seen, by the person, and in a legitimate, non-condescending way, to be aligned with and furthering the high level purpose. That could be ultimately compelling.

So, that’s my take on how the ideas in Drive align with gamification. What do you think about this? I’d love to start a conversation about this below in the comments section!

Aug 12

We Need Some Stinkin’ Badges – Gamifying Enterprise Applications (Part 4)

Arrows ("points" - get it?) (Image by Travis C, CC 2.0 licensed

In previous posts in this series I started by asking “what is the goal of gamifying enterprise apps?” Is it to make them more fun, is it to make them more engaging? The answer is “neither” – the goal is to enable the users to be more effective or better at their jobs. Making applications more fun and engaging is a plus but it should be a side effect of enabling users to be more effective. The fundamental driver behind this concept is that the users of enterprise applications are already motivated to do a good job – that’s why they have the job in the first place. And the problem of enterprise applications isn’t that they’re not engaging enough or fun (although those are problems). The problem is that the applications typically make it hard to get the job done correctly or right or easily. This isn’t good for the users or for management.

I then laid out an example of an application that I’m very familiar with, Accept360, that will be a good testbed for some ideas about gamifying enterprise applications. And then in my previous post on the subject, I listed out Gabe Zicherman’s (@gzicherm on Twitter) six rules for gamification, and started to work through how those rules applied to the example application.

Now we’re on to the next step: to start applying some game mechanics to our example app. Again, not to make the application more fun or more engaging, although those are desired side effects, but to make the application support the goals of the users to get the job done well in a more effective way.

Points and Points and Points, Oh My!

What are some approaches that we can take as a first step to making this application better at helping people get their jobs? As Mario Herger has said, “Even the s***ty stuff leads to double digit changes [in engagement].” And even though engagement is not the goal, it is a good tactic that will have impact on improving the quality of work that’s done with the application. So let’s start with a very simple addition, in fact, what’s usually the first step. We’re going to put a point system into the application. This is also the approach that Gabe Z uses in his book, Gamification by Design – he starts with adding a points system to his example.

What shall we reward points for? There are a lot of activities of people do in the application that are either considered good in general, or are indicators that the user is doing something useful. These are activities like:

  • Logging in to the application
  • Creating a new element within the application
  • Editing an element with an application
  • Participating in a discussion thread

The primary benefit of points is to encourage individuals to use the application, and the use of different point values for different activities influences their choices as to where they spend their time.

Encouraging Collaboration

But in addition to encouraging use, I have two other ultimate goals in gamifying Accept360: 1) encouraging and promoting collaboration between users and 2) promoting quality work, by pointing out and featuring excellent examples of the work products of the application – which means requirements, product plans, value propositions, and all the other types of elements that can be created within the application.

We’ll combine points with the mechanism of badges as the approach to achieving those two goals. To encourage collaboration, I can reward users who initiate collaboration, using a set of “collaborator” badges. And I can reward users who provide expertise with a set of “expert” badges. I want to encourage users who need help to ask for it, and more importantly, to know who to ask.

So for each of the activities, we’ll specify one or more badge series to which the activity contributes. For example, if you participate in a conversation about a feature, you are working on your Collaborator badge. If you create a new requirement, you are working on your Author badge. If someone votes up something you wrote, you’ll be working on a Expert badge. If someone marks one of your items as an example, you’re working on a higher level Expert badge (perhaps the “Master” badge).

This also requires adding a few more activities that are directly related to collaboration and becoming an expert:

  • Voting up an item (gives points to both the voter and the author of the item)
  • Nominating an item as an exemplar

The Story So Far

So, summarizing what we have so far. We have a points system in which the following activities are rewarded:

  • Logging in to the application
  • Creating a new element within the application
  • Editing an element with an application
  • Participating in a discussion thread
  • Voting up an item (gives points to both the voter and the author of the item)
  • Nominating an item as an exemplar

And then we also have a set of badges or recognitions that you work toward as you do the desired activities, including the following series:

  • Collaborator
  • Author
  • Expert/Master
  • Resource

That’s all we have space for in this post. There’s obviously one key piece of data missing so far, which is how many points do each of these activities get you? And we also need to explore how you build up enough points in the badge categories to get the badges. I’ll cover those in the next post in detail.

After that, we’ll need to come up with a few UI approaches for displaying all this new data – the points and badges, as well as leaderboards, at minimum.  Then we’ll playtest these settings to see if they have the desired impact. We’ll take up that discussion in future posts, and start talking about more advanced ways in which to increase engagement, which are more than just “slapping points” onto existing activities.

For one thing, we’re going to talk about turning certain activities into actual mini-games or puzzles. For example, one of the things that people doing product management should do is create what’s called a “value proposition” about their product or release. But this often doesn’t happen, and this is because value propositions are somewhat difficult to write, even though there is a canonical form, and they are extremely valuable when creating marketing materials around the product, or indeed, in deciding what features to add to the product and which ones to defer or drop.

So, a mini-game around the creation of value propositions will give users a fun and engaging way to do a task that they normally prefer to skip, despite its value. And by gamifying that task, users may even end up with higher quality results than they would have without gamified tool support.

As always, please let me know what you think in the comments, and feel free to sign up for my email list so you can get new blog posts in your email.

Jun 12

Gamification Summit 2012 San Francisco – Session Highlights

There were almost 20 sessions today at the Gamification summit – and the quality ranged from OK to excellent. In my opinion, the most interesting sessions were, in chronological order:

  • “The Future of Gamification is Emotion,” by Nicole Lazzaro, President of  XEO Design. I’d seen some of this material before on her website and in presentations on the web, but it was great to hear her in person, and to see again her very straightforward “Four Keys To Fun” model. It seems to me that if you are thinking about gamification (or making games) you need to learn these four keys and apply the concepts.
  • “Come for the Game, Stay for the Community: Building and Sustaining Lasting Engagement Online,” by Dan Porter, CEO of OMGPOP. In a very funny and profane talk, Porter described a number of the gamification-related learning that arose during Draw Something’s rise. His points aligned very well with Nicole Lazzaro’s, and illustrated the importance of really paying a lot of attention to fun, and how your users can have fun. Of course, Draw Something *is* a game, not a gamified app, so it had *better* be fun!
  • “Monopoly Academy: Winning the “Game” of No Child Left Behind through Gamification and Monopoly, the World’s Most Famous Board Game,” by Tim Vandenberg, Teacher at Hesperia Unified School. Tim uses Monopoly as the primary teaching tool in his 7th grade math class, which has, since he started this pedagogy, not only crushed the state test results, but also generated some very highly skilled Monopoly players who are competitive with nationally ranked professionals.
  • “A Game Designer’s View of Gamification,” by Richard Bartle, Visiting Professor at the University of Essex. Bartle is the originator of the player type concept of Achiever, Explorer, Socializer, and Killer, as well as the co-creator (according to Wikipedia) of the original multi-user dungeon (MUD). His funny and erudite talk focused on different approaches to dividing people up into types, and how many of those approaches are not useful for gaming (because they don’t focus on the different ways people have fun). And he noted that his player type categorization is probably not the best one to be found. He used it because it worked for his purposes, not because it was the optimal one.


Jun 12

Gamification Summit 2012 San Francisco – Day 1

A few notes and observations about the first day of my first Gamification Summit 2012 in San Francisco. Overall, this was a great day – I met quite a few people, heard quite a few good presentations, and started to get a sense of what’s going on in the gamification world right now.

The conference opened with a short introduction by Dopamine‘s Gabe Zichermann, who laid out his three pet peeves about conferences and how he was going to address them.

  • His first pet peeve was long, boring sessions. These were addressed by having each session formatted basically like a TED talk, with an 18 minute presentation and some time afterwards for audience Q&A. This had pluses and minuses – perhaps I’ll get to those later.
  • His second issue was boring box lunches that most conferences have, and since this event is being held in San Francisco, he had some of SF’s famous food trucks in to cater lunch (I had a Cubano Sandwich from a sandwich truck whose name I unfortunately do not remember). For dessert we had cupcakes from another truck – lots of them!
  • Gabe’s final issue was a desire to fix the live-tweeting aspect of a conference, to make it smoother and more integrated with the program itself, and of course, given the topic, to gamify it. The answer to this was Memecube, a new application developed by Dopamine that integrated a conference schedule and a Twitter client, along with some game aspects. Unfortunately, the morning started out with Memecube not really working, so a lot of people ended up on regular Twitter. Happily, Memecube was working fairly well before lunch, and it was a good experience at that point.

Those were the logistical changes that Gabe made. In my next post I’ll talk about some of the content we learned about.

Jun 12

Gamification of Enterprise Applications – Applying Gabe Zichermann’s Six Rules of Gamification

In my first post in this series I discussed some of the issues that enterprise applications have from a usability and engagement standpoint, as well as the key fact that the users of these apps are inclined to be motivated, both intrinsically and extrinsically, to use them. In the second post, I described an enterprise product planning application – Accept360 – that will serve as a “testbed” for applying gamification ideas.

As a refresher, the key usability and engagement issues mentioned in the first post included:

  • A choppy experience
  • Lack of flow
  • Rigidity
  • Lack of feedback to the user on whether he or she is doing a good job
  • No ability for a user to get advice or guidance in-context from another, more expert user
  • No ability for a user to be recognized as an expert

Now, in this third post we’ll start from Gabe Zichermann’s six rules of gamification and see how we can address the usability and engagement issues in the context of our sample application.

Gabe laid out his six rules in a blog post in November 2011 as guidelines for people working on gamifying applications (not necessarily enterprise applications):

  1. Understand what constitutes a “win” for the organization/sponsor
  2. Unpack the player’s intrinsic motivation and progress to mastery
  3. Design for the emotional human, not the rational human.
  4. Develop scalable, meaningful intrinsic and extrinsic rewards
  5. Use one of the leading platform vendors to scale your project (don’t roll your own)
  6. Most interactions are boring: make everything a little more fun

These rules are great, and I don’t think you can go wrong with applying them to any application to get better results and better engagement. However, I think for the purpose of our enterprise application example, we can reformulate the first rule a little bit to talk about “the user,” rather than “the sponsor.” After all, as discussed in part 1, we’re talking about a tool that motivated professionals are using (and disliking, typically) to do a job they are motivated to do. So we don’t have to consider directly what the organization considers a win, we can consider what the user considers a win – by definition that’s something that furthers the interests of the organization.

Focusing initially on rule #1, “Understand what constitutes a win for the user,” we can think of a lot of opportunities for user “wins” in a typical enterprise app – things that users cannot accomplish easily, but which a game-inspired redesign can enable. At a high level, of course, simply getting through their job is the big “win” for our users. But making the process of getting through the job better will constitute the smaller wins we’re looking for:

  • Getting out of their way, that is, “don’t make me jump through hoops to do my job.” This relates to the issue I listed above of a “choppy” experience, where you have to navigate back and forth through lots of screens to achieve a goal
  • Let me know how I’m doing and where I am – how much work is left to accomplish this goal, am I close to “good enough?” How much more to get to “Exemplary?” This is like the progress bar in games like WoW that tell you how many more experience points (XPs) you need to get to the next level. And which is missing in pretty much every enterprise application.
  • Making it easier to complete a process that I do every now and then, but I have to relearn each time – this could involve a wizard-like interaction that provides context-specific guidance for completing the task effectively. Some applications have wizards, but they are often provided for the tasks that one does regularly, which means they are actually obstacles once the user learns the application and uses it regularly.
  • Guiding and structuring collaboration on a process that requires multiple people to complete. Of all the “win opportunities” this is the one that is probably best handled by existing enterprise applications. Because the workflow of information is often a critical business requirement, many enterprise applications incorporate a workflow approach.

Each of these activities constitutes a “win” for the user.

In the next post of the series we’ll continue our look at applying these rules to improve enterprise applications. In the meantime, let me know your thoughts, questions, and concerns so far in the comments.

Jun 12

Gamifying Enterprise Applications – An Example To Work From

As I wade into what can be abstract ideas about gamifying enterprise apps, I think it will help to make them more concrete with some examples from a product I’m intimately familiar with, Accept360. This is the product for which I’m the product manager, and believe me, as a daily user of my own product, over the years I’ve experienced all the issues I mentioned in last week’s post!

Accept360 Logo

Accept360 - For enterprise product planning

Accept360 is a product planning product that includes portfolio planning, requirements management, agile management, and other related capabilities. One of the fundamental operations in Accept360 is creation of a product requirement.

In our system product requirements are somewhat complex objects that not only contain a name and description, but can also have:

  • Multiple rich text sections
  • A complete implementation estimate (in terms of multiple tasks assigned to multiple resources)
  • Weighted relationships to market elements such as the customers who have requested or will benefit from the capability and the marketing themes that the capability supports
  • The suggestions and ideas we’ve collected from customers and the market that have driven the creation of the requirement in the first place
  • Child requirements that elaborate the main requirement
  • Any number of custom properties of various types

And just to make it trickier, a requirement can have any combination of these and many other pieces of data associated with it. Depending on a customer’s product planning process, they might want or require more or less data for each requirement type.

A requirement is thus a this fairly complex chunk of data. It typically takes a product manager multiple hours or days of work to get from initial draft to delivered capability, over the course of days or weeks or even months, and with multiple conversations and collaboration sessions with other product managers, development managers, and developers (and customers, marketers, executives, etc. – the list of collaborators can go on and on).

I’ll use these capabilities of Accept360 as a testbed for how gamification can be applied to an enterprise application. (I recognize that not every enterprise app can be as cool as Accept360, but it’s still a good example.) Because of its level of complexity – all of which is simply a reality of the product planning and delivery process – there are many opportunities for applying game design and game mechanics to make the use of Accept360 a better experience. Some of the most obvious examples might be:

  • Onboarding a user – When users start working with the product, you need to let them into the world of Accept360 gently, otherwise it’s too overwhelming
  • Providing step-by-step guidance to a user the first few times he or she does a new task
  • Providing guidance at any particular point in time about where or what the user should do next – for example, if they’ve written a requirement, perhaps it should be reviewed by a colleague
  • “Scoring” a requirement – letting the user see how their require stacks up against a “best practice” requirement, and then guiding them on how to improve theirs if it comes up short
  • Getting credit for a well-written requirement – ideally this would be done via review and voting by your colleagues who need to make use of the requirement (i.e., engineers or engineering managers)
  • Getting a rank or overall score that recognizes how good you are at writing requirements, or doing any of the other myriad tasks that make up the product planning process

I am using Accept360 as the example application for applying gamification because it’s the one I’m most familiar with, but I’d be interested to hear your thoughts about other enterprise apps that are ripe for game design and game mechanics. Let me know in the comments.


Jun 12

Gamifying Enterprise Apps – Fun or Engaging? (Part 1)

Yesterday I read The Future of Enterprise Software Will be Fun and Productive by Michael Wu, Principal Scientist at Lithium and a gamification guru. He focused on “adoption” as the key metric to improve in his example of CRM, his example of an enterprise app (understandably so, since Lithium’s primary product is a social CRM application). And the key question he asked was how can we use game mechanics to make social CRM more fun, and therefore achieve better adoption?

FUN Button

Just push the "Fun" button for complete adoption! (Image by Hodgers, CC BY-SA 2.0 licensed)

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.

Fun – or Engaging?

Now, I have a quibble with Wu’s approach. In particular, I disagree that enterprise software has to be fun to boost productivity (or adoption). I prefer to focus on the sense of engagement, for several reasons. First, lots of things we like to do are not fun, but they are engaging. For example, cooking. Making art. And exercising. These are fun (sometimes) as a side effect, but what keeps you going in any of these activities, and keeps you coming back and improving your skills (or fitness), is not fun, per se.

Enterprise Applications Start With a Lot of Advantages

Getting back to enterprise software, I work from the fundamental assumption that the people working with my application want to do a good job, and they are willing to put up with some pain and inconvenience to do so – they will come to work, they will work with the prescribed software, they will go their meetings, they will collaborate with people whom they might not want to socialize with in the best of all possible worlds.

So, people are already giving us providers of enterprise software a giant leg-up on getting them engaged – they’ve committed to be there, they’re probably interested in the subject (that’s part of how they got the job) which provides intrinsic motivation, and they have extrinsic motivation to do their job (that is, their paycheck).

This is great news is the makers of enterprise applications, especially those for knowledge workers – we already start from a high position in terms of motivation for the users – they want to do a good job and they want to help their company and their customers be successful. (That’s “mastery” and “purpose,” from Dan Pink’s Drive, if you’re keeping score.)

So Where’s The Problem?

The first thing we can do with our enterprise apps is get out of the way of this intrinsic (and extrinsic) motivation to do a good job. If the app makes it harder to do a good job, for whatever reason, it’s going to cause problems not only for the user, but for the business as well.

What we find in the real world, though, is that many enterprise applications actively work against this intrinsic motivation of its users. Here are a few of the ways this happens:

  • A choppy experience – where you have to navigate hither and yon throughout the application in order to complete a process
  • Lack of flow – this is related to the previous example, but is specifically about the fact that most enterprise software is not designed to help its users achieve a state of flow, even for a single process.
  • Rigidity that doesn’t match the real process – this is the situation where the system makes you enter information before you know it, or doesn’t let you enter information that you do know because you’re not in the right phase or the right screen
  • A repeated high barrier to success, especially for processes that are important, but that the user doesn’t do very often, requiring the user to re-learn that part of the application over and over again every two weeks or every quarter
  • A complete lack of feedback to the user on whether he or she is doing a good job
  • No ability for a user to see what a good job looks like
  • No ability for a user to get advice or guidance from another, more expert user
  • No ability for a user to be recognized as an expert

Some of these obstacles can be solved just with “good design,” while others are very amenable to game mechanics and what I call socialification – a set of mechanics related to gamification but focused on social aspects such as presence, guru ratings, and feedback.

Coming Up Next – A Worked Example

In the next installments of this long article, we’ll describe an enterprise app that makes a perfect target for gamification, and then we’ll start from Gabe Zichermann’s six rules of gamification and take a stab at defining a gamified version of that app.

In the comments please let me know what you think of my characterization of the challenges of making enterprise applications engaging, and whether you think I’m right or wrong about “fun.”