Story Cards, Gamification, and Engagement

Posted by Elf Sternberg as Design, web development

I love being able to combine one of my favorite design techniques with my latest infatuation.  It makes my hair tingle.

Gamification,” as any buzzword-compliant high-priced consultant will tell you, is the process of adding game mechanics to a website in the desperate hope that trivial reward mechanisms– badges, stickers, and made-up titles straight out of your D&D years– will encourage your customers to come back and visit your website again.  At least, that’s what gamification appears to be on the surface.  That is a shallow and useless description.  Badges, “experience points” and useless labels will not encourage anyone to use your website.

Story cards” are a specification tool used in Agile and eXtreme Programming development.  A story card (usually a hand-written 3×5 card) describes the “happy path” of a user doing something useful with your software: “The user logs in,” “the user searches for a movie,” “the user watches a movie,” “the user likes a movie,” (here, “likes” is emphasized to record that “liking” is an application-specific verb).  (I use the example of a movie-selling website because I work for a movie-selling company.)  Before a development sprint, the team sorts the cards by priority, makes estimates as to how long it would take to write code that would fulfill each story, and then begins bargaining to establish who has responsibilities for each story, along with the usual ensuring that one developer’s track will not confound another’s.   A sprint is made, and then the developers assess.  A “story” is a small, atomic action a user can take with your software.

Deep, rich websites typically have dozens, if not hundreds, of stories.   Often, many of those stories will go completely ignored by your users.   They may be obscure or difficult to find in your navigation.; alternatively, their value to your users may not be obvious.  As a website owner, you want users to try out every story you have; you never know which constellation of the many stories your website supports will be the one that hooks any individual user to engagement.   If you don’t encourage your user to try out everything, you’re wasting your website.

Gamification helps prevent this waste.  It’s is an incredibly easy concept to grasp; you could write a Django app or Rails plug-in to support it in a single afternoon.   The gamify application looks like this:  For any given story (usually, “gamification experts” will call this a “user action”), the customer accrues a certain amount of currency. (Do not be confused by this word.  It does not imply money, or “virtual currency”; it’s merely a tally of whatever it is your tracking the accrual of: experience points, votes, the number of times a user has reviewed a movie, the consistency with which a user has visited your website.)  At some point (maybe even immediately), your software awards something to the user.

This is where the whole “badges, levels, titles” thing gets confusing– and annoying.  Because rarely does the user want a badge, a level, or a title.  What the customer wants is enlightenment. What you want is engagement. What your software awards to the customer should not merely be a badge, a level, or a title– your software should award the customer the information and tools needed to engage more.

Gamification is not turning your website “into a game.”  That’s stupid.  If I want a game, I’ll fire up the Playstation.  Better yet, I’ll go find my kids and a deck of Uno cards.  Gamification is the mechanism by which your website’s user manual is turned into easily digestable and entertaining awards, leading users by the hand from one capability to the next.

So get out your story cards and arrange them, not in the order in which they could be accomplished by the developer, but an order in which you want a customer to encounter them.   Sometimes, this order will be linear, but more often not.  Lay the cards on the table, with “sign up” at the top, and then the “natural” things the user would do as a second line of cards underneath, then more complicated things.  Maybe down at the bottom you could put the “epic win” cards of your website: the most popular filmmaker, or most respected reviewer, or whatever.   Now, for each card, you have to come up with a parallel game card: write down what currency we track in this story, and when the user has completed the story, what award will lead the user to other cards.  The award is a fragment of your user manual: “Now that you’ve done X, you can also do Y!”  Now, as an added layer, write a tracker for each event, tally the user’s currency, and design the award.

Gamification is the process of enlightening your users about how they can grow as users of your website.  If you have mild engagement (that is, the customer didn’t flee at the first sight of your home page), you have an opportunity to educate the user about what to do next.  You can do that with a Big Page Of Instructions, or you can do it incrementally, gradually, and with a sense of achievement.   The mechanics are easy.  So damn trivially easy I don’t see why VCs are giving third-party “gamification tracking” companies like Big Door and Bunch Ball millions of dollars.  The real trick to gamification is at the other end, at your website: your active customers know what’s epic and important about your website.  Do some analytics, figure out what your active customers already know, and then figure out how to lead new users down those same pathways in a gentle and entertaining way.

2 Responses to Story Cards, Gamification, and Engagement

Dru Wynings

September 14th, 2010 at 3:21 pm

Nice post, Elf!

You covered the main highlights, both positive and negative, of gamification. The one thing I would add is that game mechanics can be used in a myriad of different ways other than simply to lead users by the hand from one capability to the next.

Richard Bartle believed that all players (users, in this case) could be lumped into 1 of 4 different categories: Achievers, Explorers, Killers, and Socializers. The hard part is developing an experience that satisfies all of those user profiles. Personally, I believe that increasing achievers is more valuable to a website than increasing explorers… especially a site that is based on any type of user-generated content.

I don’t know about BigDoor & Bunchball, but my goal for http://Reputely.com is to make it as easy as possible to get started with integrating game mechanics the right way. Someone most certainly could develop their own in-house system, but then you’re diluting your focus. It’s all very similar to the debate over whether a startup should use SendGrid or build their own system, or add Mixpanel/ KISSmetrics or build their own.



Elf Sternberg

September 14th, 2010 at 4:38 pm

Thank you! However, I think the original point stands: the actual code for gamification is so straightforward that integrating a third party solution, especially a subscription-based solution, looks to me to be a complete waste of money. It’s much easier than social networking, and that’s not hard– witness Pinax, or Ning. It’s the actual process of going over every story card and, as Dan Cook says, creating a game/skill card for each one, that’s the hard part. There, I suspect, is where the real money lies, in future consulting fees. Someone outside a company’s heirarchy, who comes in with a different toolset, and can think in ways other than those engendered by the company.

I’ve recently come to respect consultants a lot, to my aging surprise– no matter what companies say, companies do not encourage their employees to think far enough outside any boxes. That’s what consultants are for. You’re not really paying for their experience, or their knowledge. Anyone can find that, the web is filthy with knowledge. You’re paying for them to come in with an entirely different way of looking at the problem.

Comment Form

Subscribe to Feed



September 2010
« Aug   Oct »