Slideshow Transcript

1. Slide 2: 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.
2. Slide 3: Ok/Cancel even made it into a comic.
3. Slide 4: 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.
4. Slide 5: 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.
5. Slide 6: 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.
6. Slide 7: When we get stuck in work, play is the way we get unstuck.
7. Slide 8: 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.
8. Slide 9: If we accept that play is, well, something worth serious consideration, we need to look at what we play with. And those are
9. Slide 10: Toys
10. Slide 11: Games
11. Slide 12: 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...
12. Slide 13: 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).
13. Slide 14: 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.
14. Slide 15: There have been many, many attempts to define what makes up a game.
15. Slide 17: 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 second. 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 game.
16. Slide 18: 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.
17. Slide 19: 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).
18. Slide 20: 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.
19. Slide 21: Playlist Page (Part I) adaptive path 28 June 06 Siren Soundflavor Lane Becker, Dan Saffer NOTES Downloads to Soundflavor player. If there is no player, exports like #2. 1 Exports artists and tracks as a text file. 2 GLOBAL NAVIGATION Creates a duplicate of this playlist without the user-added material. User goe 3 Clicking on this button opens the following overlay: 4 EMAIL PLAYLIST The TO field should be a dropdown that is pre- DOWNLOAD 1 Playlist Name Click to new address TO populated with any addresses previously emailed to. by Username Add EXPORT 2 New Address should be the last in the list. If it is Image FROM bill@billy selected, a text box appears to enter in a new Sample Created June 5, 2006 12:20am GMT CLONE 3 Playlist Rank #4456 This address. System should make sure a valid email Playing time: 2h, 3m Playlist Sent! format is used. From should use user's registered 4 EMAIL Dedication goes here. Click here to add one. mail as default. CUSTOMIZE Clicking on this button opens the following overlay: 5 5 Description goes here. Click here to add one. CUSTOMIZE YOUR PLAYLIST DELETE 6 BROWSE 1. Track Name by Artist Upload an image to use Click to Description goes as the background: BUY TRACK Add here. Click here Or choose a background Image to add one. Public 7 REMOVE Can be Shared Private Average Soundflavor user rating: Pick a Font Pick a Font Color Your rating: Other Playlists CANCEL RESET PREVIEW CUSTOMIZE by Username • Pack my box 2. Track Name by Artist Description goes Click to • Back in June BUY TRACK here. Click here Add • extra pluck and zeal Deletes this playlist. Loads user profile page. 6 to add one. Image REMOVE Tag this Playlist Public (default): Anyone can see it. Shared: Can be seen by anyone with the 7 Tag Tag Tag only the user can see it. Average Soundflavor user rating: Click to add another tag. Your rating: Similar Playlists CHANGES SINCE LAST VERSION OUTSTANDING ISSUES ADD INDIVIDUAL TRACKS ADD FIVE MORE TRACKS FOR ME • Pack my box by Junebug ADD A CD's WORTH OF TRACKS FOR ME • Back in June by Fritz Removed Synchronization button. This page is missing the ad • extra pluck and zeal by Monstro Comments on this Playlist • The five boxing wizards by RaeB text field COMMENT • Six big juicy steaks by You must be logged in to comment Danimal This is off da hook! – BillaBong Browse Playlists Hellz yeah! — Monstro The “rules” are often what’s captured in wireframes.
20. Slide 22: 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.
21. Slide 23: One word: e ciency. Games are an INEFFICIENT means to an end.
22. Slide 24: There are plenty of more e cient 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 e ciency. 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 e ort to overcome unnecessary obstacles.” - Greg Costikyan
23. Slide 25: 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:
24. Slide 26: Time. How much time does it take to do this task? Is the user’s time well-spent?
25. Slide 27: This is why status bars are so important. They let users manage a resource: time.
26. Slide 28: E ort. How di cult is this to do? Is there something the system could be doing to make this easier?
27. Slide 29: We’re usually pretty bad at showing level of e ort. One of the great innovations Je Veen and Doug Bowman designed for blogger was simply showing the level of e ort that was going to be required. Three steps. And then Blogger took o .
28. Slide 30: And increasingly attention. How much attention does it take to perform this task?
29. Slide 31: How much are we actively depleting users’ scarce attention with issues that they cannot solve or overly distracting them with your application?
30. Slide 32: Game designer Marc LeBlanc’s framework for the structure of games is also useful for interaction designers.
31. Slide 33: 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.
32. Slide 34: Here’s Adobe’s InDesign 3. And note The Mechanics: all the tools you need to “play the game”
33. Slide 35: The Dynamics. What happens when you “play the game”
34. Slide 36: The aesthetic response: subtle and capable.
35. Slide 37: 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.
36. Slide 38: 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?
37. Slide 39: Apple works this way. Most other companies do not.
38. Slide 41: If you only stop at usability (which is to say the mechanics and dynamics) you won’t deeply engage your users.
39. Slide 43: I am going to illustrate this section using the popular photo-sharing site Flickr.
40. Slide 44: 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 stupid.
41. Slide 45: 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.
42. Slide 46: 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.
43. Slide 47: Flickr just doesn’t reject your upload with an error message, it tells you why and often, how to correct the error.
44. Slide 48: You want to provide controls for di erent things that might be at di erent 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.
45. Slide 50: 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 di cult these days not to be--these four user types can be useful to consider.
46. Slide 51: 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 o ers insight into the type of pleasures they seek. You can adjust the game based on the type of players you want to encourage.
47. Slide 52: 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.
48. Slide 53: How designers make games is also something we should look at.
49. Slide 54: Connect & Attract Orient Advocate Extend Interact & 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.
50. Slide 55: 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.
51. Slide 56: [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 mechanics!
52. Slide 58: 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, e ort, and attention--appropriately.