Cumlng the veb

Uslng the Structure of Cumes
to Leslgn 8etter veb Apps
Lun Suffer
vhut thls tulk lsn't ubout
First of all, I want to applaud your bravery for coming to a talk with this title. I have, as I’m
sure many of you have, sat through discussions of how to make your application more like
a game.
lnupproprlute "fun'
Ok/Cancel even made it into a comic.
I will not be instructing you how to turn your financial services application or map app into
this. While I enjoy playing these sorts of games, I’m less interested in the outward
trappings of games as I am about the underlying structures.
vhut thls tulk ubout
So that is what this talk is about: the underlying structure of the games we play and how
we can incorporate them into the products and services we build.
Note that throughout this talk, I will probably be saying the words player and game a lot. In
your mind, substitute the words user and application instead!
But first, a few thoughts about play, which is why we play games in the first place.
u mummullun trult
Play is undervalued in most “civilized” cultures, but to paraphrase Ralph Koster, “Play is
how we know we’re learning.” All mammals play. It’s how we explore, try out new roles and
new ways of doing things, how we create, and fight, and love. I’m taking as my starting
point that play is an important part of what it means to be not only a human, but a
mammal on this planet.
Pluy vs. vork
Pluy ls ubout fluldlty. vork ls ubout
crystulllzutlon. Pluy ls the negutlve spuce of
work thut ullows work to contlnue.
8en Cerveny
When we get stuck in work, play is the way we get unstuck.

8oredom Aputhv
The best kind of play get us to what C calls flow--that state where the challenge matches
our level of skill. This is the region we want to get our applications into: where the
challenge and the skill are appropriately high.
vhut we use to pluy
If we accept that play is, well, something worth serious consideration, we need to look at
what we play with. And those are
1he dlfference between
toys und gumes
A toy by itself is nearly useless. It doesn’t do much until it is “activated” in a game. A ball is
a toy. A ball does stu, but by itself, a ball isn’t a game. A toy is a means to an end, but
not an end itself. A game comes ready to play, with a set of rules and materials for playing.
How does this translate into the world of web applications? There are no absolutes here,
but I think...
Toy or game? I’m pretty sure Google--at least the search engine--is more like a toy than it
is a game. It doesn’t do much until you activate it and put it to use. The reason I think it’s
a toy is that the same function--that search field--can do multiple things. You can type a
word into it, a phone number, a definition--it’s very multipurpose and relies on the users
to come up with how they want to use it (within certain parameters of course).
How about Dopplr, the travel social network? Toy or game? I think it’s a game. Yes, you still
need to do something with it (that is play the game), but it comes with a very specific set of
“rules” as to how you play the game and all the “materials” you need to play the game. You
don’t use it to do something else, like you do with Google search. You are using Dopplr for
the activity that it engenders: seeing who you know is going to be in a city you are
traveling to.
vhut ls u gume reully?
There have been many, many attempts to define what makes up a game.
Cumes ure u system
ln un lmportunt sense, ull rulegoverned
systems÷lncludlng luw, polltlcs, wur, morullty,
educutlon, economlcs, und lunguuge÷ure
gumes, us muny people huve noted.
Stephen Snldermun
Some churucterlstlcs of gumes
Resource munugement
Goals: objectives. If there is no goal, the games is meaningless
Non-linear: they depend on decision-making. Games are a series of decisions. At every
point, players evaluate the state of the game and make a decision about what to do.
Interesting decisions make for an interesting game.
Rules: Designers provide them, players use them to create the game. More on that in a
Resource management: more in a moment.
Information: the game has to provide enough relevant information to make sensible
decisions. Players need to know the range of options available to them while playing the
Goal here: communicate to friends.
Decisions to be made: what to communicate and who to communicate to.
Rules: Here’s how you enter in what you are doing.
Resource management: Here, it’s your friends, right?
Information: Indicators of resources to manage, messages from friends, and how you can
send a message yourself. It doesn’t overload you with extraneous information here.

A fundamental part of any game. When you buy a game, you are basically buying the rules
(and the materials to make the rules come to life).
Basically, when we use a web application, we’re buying the rules for that product. Sure, you
can try to use Yahoo Maps to do something other than show maps, but it won’t work very
well for that. The rules are: enter in an address and we’ll show you that on a map, how to
get there, what’s near there, etc. Those are the rules. And what we spend a lot of our time
on as designers is defining the rules, right? When you push this button, that happens. Tech
manuals and Help Screens are basically rulebooks for playing our game.
adapti ve path
Playlist Page (Part I)
Lane Becker, Dan Saffer
28 June 06
Playlist Name
by Username
Created June 5, 2006 12:20am GMT
• Pack my box by
• Back in June by Frit z
• ext ra pluck and zeal by
Monst ro
• The five boxing wizards
by RaeB
• Six big j uicy st eaks by
Browse Playlist s
Similar Playlists
Other Playlists
by Username
• Pack my box
• Back in June
• ext ra pluck and zeal
1. Track Name by Artist
Can be Shared
Dedication goes here. Click here to add one.
Description goes here. Click here to add one.
Privat e
Click to
Description goes
here. Click here
to add one.
Click to
Description goes
here. Click here
to add one.
Tag Tag Tag
Click to add another tag.
Tag this Playlist
Playing time: 2h, 3m
Playlist Rank #4456
2. Track Name by Artist
Your rating:
Average Soundflavor user rating:
Your rating:
Average Soundflavor user rating:
2 Exports artists and tracks as a text file.
Downloads to Soundflavor player. If there is no player, exports like #2.
Creates a duplicate of this playlist without the user-added material. User goe
4 Clicking on this button opens the following overlay:
The TO field should be a dropdown that is pre-
populated with any addresses previously emailed to.
New Address should be the last in the list. If it is
selected, a text box appears to enter in a new
address. System should make sure a valid email
format is used. From should use user's registered
mail as default.
new address
5 Clicking on this button opens the following overlay:
Upload an image to use
as the background:
Or choose a background
Pick a Font Pick a Font Color
6 Deletes this playlist. Loads user profile page.
7 Public (default): Anyone can see it. Shared: Can be seen by anyone with the
only the user can see it.
Comments on this Playlist
This is off da hook! – BillaBong
Hellz yeah! — Monstro
COMMENT t ext field
You must be logged in to comment
Click to
This page is missing the ad
Removed Synchronization button.
The “rules” are often what’s captured in wireframes.
Rules muke uctlvlty posslble
[Pluyers| uccept rules so thut they cun pluy u
gume, und they uccept rules so they cun
pluy gume.
8ernurd Sults
One of the reasons people use Yahoo Maps is that they want to play the “maps game” with
Yahoo’s rules, not with Google’s. Or visa versa. You can roughly play the same game with
either, right? You can still map locations, get driving directions, etc. It is just HOW that is
accomplished, and that’s what the rules dictate.
Cne mujor dlfference between
gumes und whut we do
One word: eciency.
Games are an INEFFICIENT means to an end.
There are plenty of more ecient ways to get to the end of a marathon than by running. A
car, a bike, taxi, helicopter...but games aren’t about that. However, most interaction design
IS about eciency. But if I design an application that made you type every letter twice in a
text field just for the fun of it, you would kill me.
“Games are the voluntary eort to overcome unnecessary obstacles.” - Greg Costikyan
Munuglng Resources
Most games are about managing some sort of resources. In chess, for example, this is
retaining your pieces. In soccer it is about control of the ball. In most interaction design,
the resources we are managing are often these three:
Time. How much time does it take to do this task? Is the user’s time well-spent?
This is why status bars are so important. They let users manage a resource: time.
Eort. How dicult is this to do? Is there something the system could be doing to make
this easier?
We’re usually pretty bad at showing level of eort. One of the great innovations Je Veen
and Doug Bowman designed for blogger was simply showing the level of eort that was
going to be required. Three steps. And then Blogger took o.
And increasingly attention. How much attention does it take to perform this task?
How much are we actively depleting users’ scarce attention with issues that they cannot
solve or overly distracting them with your application?
1he Structure of Cumes
Game designer Marc LeBlanc’s framework for the structure of games is also useful for
interaction designers.
1he purts of u gume
1he muterluls we need to pluy
1he behuvlor of the gume
1he emotlonul content of the gume
Mechanics: stu like dice, the game board, a computer, etc. Also includes rules, which we
discussed earlier.
Dynamics: emerge from the mechanics. What happens when the game is actually played.
Hard to determine from the mechanics alone!
Aesthetics: The responses players have while playing. How it makes the player feel.
Here’s Adobe’s InDesign 3. And note The Mechanics: all the tools you need to “play the
The Dynamics. What happens when you “play the game”
lnLeslgn remulns the most capable puge luyout
softwure uvulluble. 1he more l use thls new
verslon, the more l uppreclute the subtle
retoollng throughout, not just the obvlous new
Culen Crumun,
The aesthetic response: subtle and capable.
Eow gumes work
whlch creute
This is really how users experience it. And too often, this is how we design applications,
right? We start with the mechanics: how stu works, here’s the business logic we need to
consider, here’s a button, here’s a checkbox, etc.
Eow gumes work
whlch creute
When we should really be designing like game designers do: you start from the opposite
side of the equation. We should figure out the aesthetics--what should this feel like? what
is the emotional response to this application?--and work backwards from there. What
dynamics will create these feelings? And what mechanics will support that?
Eow gumes work
whlch creute
Apple works this way. Most other companies do not.
Eow you cun work thls wuy
Mood bourds
Scenurlos to ldentlfy uesthetlc context
ldeully bullt on reseurch
llndlng "emotlonul moments' ln un upp
"Mood Mup'
vhy you should work thls wuy
Aesthetlcs creute lmpresslons thut cun
deter or enguge users
Usublllty lsn't everythlng
More emotlonul = more sss
If you only stop at usability (which is to say the mechanics and dynamics) you won’t deeply
engage your users.
Eow the best gumes work
(und why we cure)
I am going to illustrate this section using the popular photo-sharing site Flickr.
Cumes need un lnternul loglc
Pluyers should ulwuys blume themselves
for fullure. lf the gume kllls them off wlth
no wurnlng, then the pluyers blume the gume
und sturt to dlsllke lt.
len 8lrdwell
Applications need a logic as well. If I can cut and paste in one location, I should be able to
do it elsewhere. If an application blocks me from doing something logical without any
explanation, it is frustrating and incomprehensible. We blame the application for being
If I can hover over one area of Flickr and it becomes able to edit, I’d better be able to do
that elsewhere (and I can). The logic is consistent and when it comes time to edit, I can
because I understand the logic. This logic extends to a lot of things, like tags as well.
"Percelvuble Consequence'
[P|luyers know whut to expect from the
world und thus ure uble to feel ln control of
the sltuutlon...Any uctlon you tuke [should
result| ln dlrect, vlslble feedbuck.
Loug Church
When users attempt to do something the application doesn’t allow them to do, they should
understand WHY they can’t do that. The reaction by the application should make it
apparent what needs to be done to make the action possible.
Flickr just doesn’t reject your upload with an error message, it tells you why and often,
how to correct the error.
Controls ut multlple levels
Cften pluyers work on severul gouls ut
dlfferent levels und on dlfferent tlme scules.
1he process of uccumulutlng gouls,
understundlng the world, muklng u plun then
uctlng on lt ls u powerful meuns to get the
pluyer lnvested und lnvolved.
Loug Church
You want to provide controls for dierent things that might be at dierent time scales. So
you have quick, easy-to-do tasks that are done often. Like, say, cut and paste or sending a
message. Then there are long-term goals that are also associated that need to be
accounted for, like say, account management and such.

In this, the era of Personas, it’s probably not political to say there are certain types of
players of games without researching them, but Richard Bartle found four types of users in
MUDs and if you are working on any type of social application--and it is dicult these
days not to be--these four user types can be useful to consider.
lour types of MUL pluyers
1uckle gumereluted gouls
llnd out everythlng they cun
locused on communlcutlon fucllltles
Cuuse dlstress to others
Achievers want to do everything they can with your app. Explorers want to find the hidden
parts of your app. They are the super-users. Socializers want to use your app as a means
of creating, sharing, and communication. And killers are those users who use the tools of
the app to annoy or harass others.
How players interact with the game oers insight into the type of pleasures they seek. You
can adjust the game based on the type of players you want to encourage.
Marshall McLuhan noted about 40 years ago that people aren’t focused on goals, they want
roles to play. Interaction design can give that to people and not just through games. When
you are on Twitter, you are playing a role. When you are on Facebook, you are playing a
role. When you are on your banking site, you are playing a third role, and so on. As
designers we need to be aware of this. Your application is a place where users will play a
role. What role will that be? You can help shape it.
Cume productlon
How designers make games is also something we should look at.
& Attract
& Retain
Source: Shelley Evenson
This model of Shelley Evenson’s reminds us of all the parts of an experience we need to
keep in mind when designing our applications and this is something that game designers
do well.
We should never forget that the anticipation of playing a game, along with purchasing,
packaging, reading about, observing others play it, etc. can all extend the game
experience. This is otherwise known as marketing, and we should work with marketers to
make use our application experience extends to the marketing.
Look at the Wii for instance. Half the fun of it is watching other people play it. The
attraction is undeniable, as is the advocating on behalf of others.
lterutlve Leslgn
1he fun und excltement of pluylng cunnot be
culculuted ln un ubstruct fushlon: lt must be
Relner lnlzlu
[Games are always prototyped as they are developed because game designers know it is
the only way to check both the DYNAMICS and the AESTHETICS. The rules (MECHANICS)
aren’t enough, and those are the only things you can really capture in paper prototypes or
wireframes. And when testing, you need to plan the exact moments you want to monitor
and test and you have to ask about the aesthetics and the dynamics, not just the

Pluy ls lmportunt: we leurn und explore
uslng pluy
8oth gumes und products ure systems
mude up of deslgned rules
Cumes (und uppllcutlons) ure ull ubout
how users muke declslons
Users scan the “board” examining the state of the game/application in order to make the
right decisions. As designers, we need to provide them the right amount of information to
manage their resources--time, eort, and attention--appropriately.
Structure your upps so thut the
uesthetlcs und dynumlcs drlve the
mechunlcs, not the other wuy uround
Muke your rules conslstent und user
uctlons huve percelvuble consequences
Provlde controls for multlple levels und
dlfferent tlmellnes
leep the four types of pluyers ln mlnd
und udjust your gume uccordlngly
Remember thut the product ls purt of the
cycle of experlence und deslgn wlth thut
ln mlnd
1est uesthetlcs und dynumlcs through
prototyplng us you deslgn
Lun Suffer