This post is part of the Game-Like Mechanics series.
Product people in consumer internet have game envy. Everything should be as fun and engaging as Super Mario Kart. This agenda is emboldened by the success of Foursquare - the half-app, half- alternate reality game. Game mechanics such as points, leaderboards, badges, and mayorships are what make Foursquare more engaging, addictive, and successful than all the other location apps.
Now other apps are eager to jump on the game mechanics bandwagon. Badges, for example, are suddenly cropping up everywhere. But in some cases, their use feels contrived, or even worse, users begin to feel manipulated. It's important to realize that explicit game mechanics may not be appropriate for all apps.
Instead, consider incorporating game-like mechanics to engage users. These are design patterns that come from videogame theory, but importantly, they aren't overtly videogame-y. Since they don't cry out: "I'm from a video game," game-like mechanics may be suitable for a broader range of apps.
I stumbled upon game-like mechanics whilst cataloging user engagement techniques for my own design practice at Hunch. When I shared my findings with colleagues and friends, there was disagreement over whether certain patterns were actually game mechanics. These patterns engage users using videogame theory, but aren't recognized as iconic like leaderboards and badges. Thenceforth I've been calling this class of patterns game-like mechanics. I used my cohorts' objections as the litmus test.
I expect to write a short series about game-like mechanics. One pattern per post. The first pattern I want to share is...
THE "IN-GAME" TUTORIAL
Onboarding is often mistaken for account creation. But user acquisition is actually just the first of four steps. Accommodation, assimilation and acceleration are the other steps. In videogame speak, the onboarding process is accomplished by an in-game tutorial. Adventure and RPG games use warm-up levels to get your basic information, show you the ropes, and accelerate you into the flow of the game. A tutorial can take five minutes. Or it can span six mini-missions and take an hour, as in the case of Kingdom Hearts 358/2 Days. (Not that I'm bitter or anything.)
If your web or mobile app is complicated like Kingdom Hearts, you should definitely consider a tutorial system. Because dumping users to the home screen to figure out their own use case is UX purgatory. For an example of a tutorial system in a complicated product, we look at Facebook. After you create an account, you're brought to a Welcome page. The page lists six basic, actionable steps for the user to complete - search for friends, upload photo, fill out profile, activate phone, find people, and set privacy. When possible, the form or button required to complete the step is in-lined so the action can occur right then and there. Facebook's tutorial isn't exactly fun, but it gets the job done.
A lighter-weight tutorial system is the hovering callout where the voice of the app speaks to you. For example, after you create an account at Aardvark and land on the home screen, a callout tooltip in the upper right corner tells you that the first thing to do is to ask a question. The link is included. Simple and elegant. After you've done that, the tutorial callout tells you to try some other action, and so forth.
Note that in-game tutorials are different from tours. Tours might explain how to do something, but tutorials get you to take steps yourself. A powerful idea.
OkCupid has one of the most impressive in-game tutorials. After creating an account, OkCupid prompts users to take one action that will advance their progress on the site. In total, users are asked to take ten or so steps toward crafting a profile (e.g. add a photo, add some tags) and connecting with the community (e.g. write a forum post). OkCupid's tutorial is better than the rest because it rewards users for completing steps. They accomplish this with help from another design pattern: the PROFILE COMPLETION BAR.
Read part II here →