Archive for the ‘design’ Tag

Interview with Jesse Schell

Last week I spoke with game designer Jesse Schell, the highly influential author of “The Art of Game Design”, professor at Carnegie Mellon, and CEO of Schell Games.  His presentation from the 2010 DICE Summit, in which he mapped out a future where gamelike experiences will be integrated into everything from toothbrushes to bus rides, went viral and sparked widespread controversy.  We talked about the presentation, the promise for games to do good in the world, and how UX designers should approach game-related projects.

The second chapter of your book is dedicated to discussing games as enablers of experiences.  Why the emphasis on that idea right at the beginning of the book?
It’s important because people who are trying to design games are so quick to go to anything tangible.  They want to talk about the particulars of the design right away, how it works and what it looks like.  But what the designer’s actually doing is building an experience, and we should never lose sight of that.  That’s the real goal.

Your DICE presentation predicted that in the future gameplay will be thoroughly mashed into everyday user experiences.  Do you envision the impetus for that coming from the game designers, or from the designers of conventional user experiences?
I see it coming from both directions.  Reality and games are really reaching out to each other right now, and meeting in the middle.

So what core competencies would conventional user experience designers need to develop to game up their interfaces?
Core competencies isn’t the right way to think about it — it’s not learn a little about this or that.  You’d first need to make a fundamental shift in your perspective, and then you’d need to practice.  You’d need to turn away from efficiency and toward entertainment.  So for example, if I were to give you a tax application with just one big red button that you pressed and boom, your taxes were all done, that would be ideal.  If you did the same thing for Gears Of War, that would be the worst game ever.  So people who are gameifying conventional interfaces can get themselves into trouble.

What advice would you give to someone who’s thinking about incorporating a gamelike experience into a conventional UI?
You can’t just say “Hey, people like games, therefore people will like this.”  That isn’t necessarily true.  And people don’t necessarily want a user interface to be a game per se, but to have gamelike qualities.  There are many things that games are especially good at.  They can provide clear feedback, the possibility of success, mental and in some cases physical exercise, the opportunity to satisfy your curiosity, a chance to do problem solving, or a feeling of freedom.  So you should be asking “What are the elements of games that people find pleasurable?”

Some of the reaction to your presentation has seemed fearful, with speculation of Orwellian implications.  Did you anticipate that response?

Well I think there is some reason for concern, and I really wanted people to have that discussion.  This is something that’s definitely going to happen and it can be a very good thing, but it can also be misused.  For example, you start getting into a lot of ethical problems with advertising because games can be such a powerful medium to influence buying behavior.  It’s one thing when you use a compelling game mechanic to create an experience that you really get into, but it’s another if you’re using it to get people to buy something that could be damaging to their health.

Can games can be used to achieve positive social ends?
Absolutely.  Certainly educational.  If you have the ability to ability to influence behavior in a negative way, then you also have the ability to influence it in a positive way.

Do you think that video games have a place in the classroom?
Sure.  There are a lot of challenges with games in the classroom.   In general they’re best suited for use outside the classroom because games tend not to work well under time constraints.  They’re better as homework.  But there is a place for them in the classroom, and it’s probably best when the teacher serves as a game master.  So let’s say you do a live simulation in class where the teacher sets up the situation then observes and augments it as it goes, with the goal of creating a teachable moment.  That’s something that simulations are really good at.  Teachers know you don’t just pour something into the student’s ear, you have to pry their brains open so that they actually care.  The teacher can use games to engineer that moment, and then drive discussion about how it could be done differently.  I’ve seen this done a few times in training games for firefighters, doctors, and nurses, but it can happen almost anywhere.  The key is to shift from games as a replacement for the teacher and to something that empowers the teacher.

Can games be persuasive?
Games are best at being persuasive when they’re persuading you of the truth.  They can be particularly good at illustrating complex systems.  If you have an argument about whether a nuclear reactor is safe, people may or may not give credence to your words.  But a simulation can prove that it is or isn’t safe because you can actually experience it.

This property of games can also make them very useful in, say, political situations where people need to make decisions about complex systems that are difficult to understand. A team from CMU made a game called Peacemaker, intended for Israeli and Palestinean students.  People on either side of the conflict tend to assume that the whole thing will go away if the guys on the other side just stop being jerks.  Then the students get in the game and start working on solutions, and they discover that what they thought was simple is actually unbelievably complex.  So it elevated their point of view on the conflict.

In your mind, what’s the most exciting work being done in line with the ideas from your DICE presentation?
I like cool entertainment experiences that make people’s lives better. Some of the charity-based ones are really interesting, and can even be meaningful and important.  Looking forward, I’m really excited to see it incorporated in theme park experiences.  You don’t really see interactive vacations, and I think there’s a lot that can be done there.

But many of the attempts out there are boring.  There’s a glut of self-improvement games that are just flops and failures.  Most of them don’t really get the idea of rewards.  There’s a great book called “Punished by Rewards” that I encourage everyone trying this to read.  We have 30-40 years of psychological research proving that if you bribe someone to do something, people will come to despise doing that thing.  Why?  Because of the tricky nature of freedom: when someone pays you to do something, you’re not doing it for the intrinsic benefit anymore. An awful lot of things that will fall into that trap.

You’ve been critical of Foursquare in the past.  Do you take issue with its execution?
No, I think that Foursquare is inherently flawed.  The challenge curve is messed up.  It’s very similar to Tamagotchi, and it’ll probably will have a lifespan similar to the Tamagotchi.  The game as it stands requires no skill.  It also doesn’t fit conveniently into your life; you have to fit your life into it.  So if you’re in random places at random times, you’re going to lose at Foursquare.  You can only win by engaging in boring repetitive behavior, and it’s not fun to actually do that.  You’re always rating yourself against the most obsessed people in the world.

But wasn’t Tamagotchi an important forerunner to other virtual pet games, like the Sims?  Doesn’t that show that there’s some potential there?
Tamagotchi took a simple fantasy, the Sims turned it into an elaborate fantasy.  When you think about it, almost all indoor games have some kind of fantasy component to them, even simple things like chess and checkers.  Foursquare has no fantasy in it, so there’s just not much to expand.  If you take Foursquare and add fantasy, you get larping.

Fifteen years from now, what do you think games are going to be like?
The future of games is going everywhere.  They’re creeping into every aspect of our lives.  Over the long term, one of the big trends will be game worlds with many points of entry.  You won’t only get into World of Warcraft from the PC, but also from mobile and console systems and maybe even in your car or in a theme park.  I also think that speech, where you can talk to a game and it can understand and respond to you, will really change gaming by bringing in real expressive emotion.

Thanks so much for your time Jesse.

Advertisements

The classroom as a game

Lee Sheldon teaches game design at Indiana University.  His methods are a bit unconventional.  His class on building massively multiplayer online games is itself structured like an MMO.  Students work in teams called “guilds”, grades are awarded with experience points, and exams are boss fights that guilds work together to complete.  He’s recently started a blog on the class.

One of the themes I’ve been developing is that many things we do in everyday life are indistinguishable from games, but we’re just not used to thinking of them that way.  There’s real value in that insight, because interfaces that cater to those activities can benefit from the same design principles that make games so compelling.

And the Nobel prize for video games goes to…

One of the most interesting practical applications of video game design I’ve come across is FoldIt, a project out of the University of Washington that has game players folding chains of proteins.  It’s actually a lot more awesome than it sounds.

Biochemistry is hard.  Protein molecules grow to extraordinary lengths, and can be folded into a dizzying variety of different shapes following a set of basic rules.  And a single protein can have completely different effects depending upon the way it’s folded.  Fold one protein this way and you have a normal part of the human body; fold it that way and you’ve got mad cow disease.  Unraveling the complicated effects of different protein shapes is an extremely important area of inquiry in modern biochemistry.

A rules-based problem with countless numbers of possible solutions?  On the surface it sounds like a job for SUPERCOMPUTER!  It’s not.  Computers certainly provide vital support through modeling complicated protein structures in real time, but it turns out that they’re not especially good at figuring out how to twist protein chains into new shapes that obey all of the rules.  I recently spoke with Seth Cooper, one of the developers of FoldIt, who told me that left on its own a computer “just kind of flails around, trying random moves to get the pieces to fit together.”  Since there are so many possible combinations to run through, this sort of brute force approach gets results very slowly.

On the other hand, human intuition can recognize patterns and anticipate strategies that are lost on machines.  But human beings come with their own set of problems — in particular, you need to give them a reason to do something.  As Luis Von Ahn pointed out, you can motivate people with material things like money or goods — but inexpensive and intangible things like recognition, praise, and social credit can often be just as effective.

And that’s why the designers of Fold.it decided to make their human-guided protein folding interface into a video game.  Making progress gets you points, points get you onto leaderboards, and leaderboards give you recognition.  This simple formula has been sufficient to get tens of thousands of players to volunteer their time to a science which, in many cases, they have no background.  Though it must be pointed out that it’s at least conceivable that a by playing this game, you could actually win a Nobel prize.

White House Launches Games for Health Initiative

Can video games get kids to go easy on the Lucky Charms?  The Obama administration thinks they might be able to.

In a letter to attendees of the annual Game Developers’ Conference last week, Michelle Obama issued a challenge to develop games that would educate kids about eating better and living healthier lives.  Prize money will be awarded to the best entrants, as judged by a panel including Zynga’s Mark Pincus and professional TV dancer Steve Wozniak.

Can this work?  I absolutely believe it can, but I’m more concerned that it might not.  Let me explain.

On the one hand, I fully believe that games can be used to bring about change in people.  In his speech at the DICE summit, game designer Jesse Schell proposed games to get people to do anything from brushing their teeth more often to helping their kids with their homework.  Popular games like WiiFit and Brain Age improbably get people to exercise their bodies and minds.  Games are intimately tied to motivation, and can be powerfully persuasive ways to get people to do something or adopt a certain point of view.

On the other hand, I’m concerned that this competition (itself a motivational game!) might not be structured to elicit the best solutions.  To be successful, a game must first and foremost be a game.  If an educational mission (however noble) supersedes the gameplay, the experience can become heavy-handed and unenjoyable.   I think there’s a danger here that the prize competition could reward entrants that most conspicuously promote the healthy eating idea, rather than those that really engage the player.  A game can’t influence people if no one actually wants to play it — call it “The Bible Game” problem.

But still, the White House is is doing something really significant by endorsing the idea that games can achieve real-world objectives.  I think that’s a sign of shifting expectations about the role games have to play in all of our lives.

Send questions for foursquare

This weekend I’ll be interviewing Dennis Crowley, creator of foursquare.  We’ll be discussing the decision to design what could have been a conventional UI as a game-based experience.  If you have questions you’d like me to ask, please post them as comments to this blog.

In Defense of Documentation

At recent conferences and in discussion groups, I’ve found it’s become increasingly popular to deride design documentation as time-wasting, inscrutable, and pedantic.  There’s a growing drive to jump directly into development, and manage design on the fly.  Few people are providing cogent arguments to the contrary.  As an IA who prides himself on the quality his documents, I feel the need to address the role of the spec in the age of Agile.

Bad documentation is real, and must die

There’s no doubt that there are some absolutely terrible documentation practices out there.  If you’re writing several dozen pages of design strategy in plain prose, you shouldn’t be surprised when no one bothers to read it.  A core measure of a development effort’s success is its efficiency, and documents that slow down the process should be hastily ditched.  It makes no sense to compound the time lost in writing poor documentation with even more time spent reading it.

Good documentation is also real

Good documents are completed quickly, express ideas efficiently, expedite development, build trust among team members, and allow people to achieve things that would otherwise be impossible.  People enjoy reading and discussing them, and teams of designers, developers, writers, and clients work as a whole to review and iterate them.

An analogy

Two years ago my wife and I decided to upgrade to an HDTV.  The problem was that we were going from a 24” tube set to a 46” flat panel, and the new set wouldn’t fit our existing furniture.  Even worse, the money we were spending on the TV precluded us from buying new stuff.  So I decided that I’d build a TV stand myself.

"Wireframe" of our TV stand

"Wireframe" of our TV stand

Now you need to understand that I’m not the sort of person you might describe as “handy”.  I’d never built so much as a birdhouse, and my high school didn’t even have a wood shop.  I had absolutely no idea how to construct a physical object.  Furthermore, my wife strictly forbade the use of any saws or sharp objects for fear I might cut off something important.

So I decided to create a physical object in the same way I would create any virtual one: I drew up a wireframe in Visio.  Before picking up a hammer or even buying the wood, I first mapped out the whole vision on paper.  I shared early top-level designs with my wife, we talked them through, and I modified the plans until we agreed on the approach, and then I filled in all the low-level details.

The completed TV stand

The completed TV stand

I’m pretty pleased with the result (see the picture at right).  It’s not exactly Herman Miller, and it weighs about 50,000 pounds, but it meets our needs precisely and cost me just under $100 to make.  And this example illustrates a few key advantages to a good documentation process over going straight to development:

  • Faster completion time. The documentation itself only took two days to develop, and since everything was planned out beforehand there was no wasted development time.  I got the project done in six weeks, much faster than I could have without the documentation.
  • Control of design. There’s a terrific symmetry between the design on paper and the finished product.  This was very important, because a lot of factors had to be balanced in the design: ensuring structural integrity, fitting all of the components in without making the stand too tall, and creating aesthetic beauty.  Jumping straight in, I wouldn’t have been able to manage that balance.
  • Planning around restrictions. It’s hard to build something out of wood when you can’t use a saw.  Lowe’s could cut the wood for me, but they could only do straight cuts at 90° angles to the board.  This was a built-in hardware limitation – not a deal-killer, but it required some creative planning.  Accounting for restrictions in the documentation keeps them from becoming show-stoppers later on.
  • Lower risk. Of course I could have jumped straight into the build, but that would have been much more risky.  I would have wasted a lot of lumber.  It could have come out looking terrible.  I could have discovered halfway through that there was a much better way of doing it.  Designing it on paper first was harmless, and maximized my chances of success later on.

Hmm, now what could that have to do with UI design?

By now this connection should be abundantly obvious.  In fact, from the most general point of view of process there is no useful distinction between building a TV stand and building a website.  Both require design and development efforts.  Both involve costs and risks.  Both produce an end product that needs to satisfy many needs equitably.

Quality documentation allows people to achieve things that are otherwise impossible.  The human brain can only do so much on its own – we need to extend its capabilities by processing things on paper, with our hands, and through conversation.  The task of designing software is often so complex that you can’t even grasp the full problem until you’ve written enough of it down.

But perhaps most critically, a good document provides for a foundation of trust to be built between team members.  Developers shouldn’t have to do design – it’s a distraction from their responsibilities, and exposes them to accountability for decisions that should have been handled by someone who’s paid to make them.  If the developers can trust that all foreseeable design decisions have been anticipated and built into the documentation, they’ll stick to it zealously.

What about Agile?

“Agile” is the name given to a process of rapid iterative prototyping and efficient communication.  I think it’s a terrific thing, because it allows concepts to be tried out and massaged into good shape in short order.  I employed a bit of Agile while building my TV stand – using scrap wood to figure out to make dowel joints and apply a stain, and grabbing whatever was within reach to get a job done.

But Agile has spawned a certain animosity toward even very high quality, efficiently produced, time-saving documentation.  I don’t think that’s Agile’s intention.  I think it rightfully seeks to eliminate time wasted producing documents that no one will bother reading, but perhaps its mantra has been repeated so often that it’s grown beyond its original meaning.  Played out to its logical extreme, ditching documentation would lead to disaster on all but the simplest projects.

So what should we do?

We need to reestablish the role of documentation in the product development lifecycle.  To do that, we first need to come to grips with the fact that what people have received in the past has been found wanting.  So we need to make a few key changes:

  • Crank it out. We need to be able to turn documents around faster than developers can build to them, or else we’ll become a bottleneck.  Our documents should be done in the simplest form possible, with no excess ornamentation or verbosity.  Ugly is efficient.
  • Communicate efficiently. We do after all work in usability, so our top priority should be to keep the needs of the document’s consumers in mind.  Integrate images with text effectively, speak clearly, and edit out anything that doesn’t solve a problem.
  • Know your medium. We don’t need to be coders, but if we understand how HTML, CSS, scripting, and databases work we’ll be able to take advantage of the strengths of these technologies.  Marshall McLuhan was right – the medium is the message.
  • Make people’s jobs easier. Bad documentation adds to other people’s workloads.  Good documentation lightens them.  Everyone will be happy to have something that reduces the total number of decisions they need to make.  Our documents should take control of everything that will affect the usability of the system.
  • Produce gold. People need to believe you’ll design something that will make everyone involved look good, and bring them to a better outcome than they could hope for without us there.  Get everyone’s input into the document as it’s developed, and iterate it repeatedly to build confidence in the finished product.

Final Fantasy User Interface

Over the past few weeks I’ve been playing a game for the PS2 called Final Fantasy XII (sounds dirty, but it’s not). I haven’t been a big fan of the series, but this one is really very good. I’m finding it especially interesting from the perspective of user interface design.

FFXII is a role-playing game, in the vein of Dungeons & Dragons. Generally speaking, these can be fairly complex endeavors. You control multiple characters, each of whom has its own attributes that evolve over the course of the game, and you need to attend to their complement of weapons, armor, and accessories, as well as micromanaging their individual actions in battle (I know, fun times). Creating a UI that allows players to sort through all of this complexity is a real challenge, but the design in this game is just fantastic. I expand on a few examples below.

Equip (click to enlarge)

Screenshot 1: Equip

Equip screen

This first screen shows the interface for equipping a character with body armor (click the screenshot to enlarge it). The list of available armor is on the right side, and colored dots show what each of the 6 characters is currently wearing. So character 4 is currently wearing bronze armor, and we’re considering upgrading him to diamond armor (the current position of the cursor). The list of attributes on the left shows what the exact effect of that upgrade will be, with the blue numbers indicating the new values. The character’s defense will go up fivefold, while his strength will increase by a more modest amount. Players can compare different armors just by moving the cursor up and down and noting the attribute changes each one affords.

Another little nuance is that certain characters are only allowed to wear certain types of armor. This is indicated by a circle under that character’s face. If the character can’t wear the armor, we see a dot instead of a circle. So we can tell at a glance that Basch is the only person who can wear diamond armor, while anyone is welcome to leather clothes. I like too that faces are used as column headings here: it’s both space-efficient and takes advantage of the fact that people are innately good at recognizing faces.

Gambits (click to enlarge)

Screenshot 2: Gambits

Gambits

Final Fantasy XII includes a novel gameplay element called the gambit system, which is a sort of very simple programming language. Rather than laboriously commanding each character action by action in battle, you can set up a list of things they should do automatically whenever a certain condition is true. This is the gambit screen for a character named Penelo, who is currently assigned five active commands. The fifth one says that if any foe is nearby, she should attack it. But it’s superceded by all of the commands listed above it, which include healing poisoned allies or curing them if their health drops below 70%. It’s kind of funny that the condition statements are purchased or won over the course of the game, with the most helpful ones being more difficult to attain.

The system is flexible and very easy to use. You just pair a condition statement with an action, turn the gambit on and you’re ready to roll. Each gambit can be picked up and repositioned in the list to ensure the actions are executed in the proper order. The interplay of different characters in different battles against different enemies makes the gambits rather involved. It’s a great use of programming logic, allowing the player to assemble a sequence of if-then statements and then test out their effectiveness in different scenarios.

Battle (click to enlarge)

Screen 3: Battle

Battle head-up display

When in battle, an overlay provides a remarkable amount of information without obscuring your view of the action, as shown in screen 3. You’re able to keep track of each character’s current and maximum health, current and maximum magic power, available actions, next action, how soon an action will be performed, which character is leading, whether their gambits are active, whether a character is being targeted, the enemy’s health, and your character’s position in a map of the world. That’s really quite a lot, yet it doesn’t feel at all obtrusive. The economy of space strikes me as very Tufte.

Scratching the surface

That’s really just the beginning; I could go on at some length describing the menu structure, automated mapping, selection controls, cursor behavior, etc. There are so many good things happening in this game, many of them very small touches that are easy to overlook because they feel completely natural. Far from treating the game as frivolous, it’s clear that the designers put real care into this UI.

Amazon’s product rating system

A recent article on Boxes & Arrows discusses rating and review systems on sites like NetFlix, eBay, and Amazon. I think these types of systems are a fantastic basis for a socially constructed experience. They take advantage of the Web as a mass medium, they can include both quantitative and qualitative components, and they can be really useful to people.

The article tweaks Amazon a bit for its “most helpful review vs. most critical review” idea. Authors Alex Kirtland and Aaron Schiff argue that people writing those reviews can be evaluating a product on completely different criteria, so a reader can’t depend on them to be comparable.

I think they’re missing the real beauty in Amazon’s design. There are three components to it:

  • A star rating. This creates a quantitative value that, in aggregate, gives users a basis for quickly comparing buyers’ overall happiness with a product.
  • A review. This answers the question of why a particular rater gave a product a positive or negative review.
  • A thumbs up/down rating. Assigned by people who read the reviews, and rate it as either helpful or unhelpful. This is a rating system on top of the rating system, and simply counts the total number of positive against negative votes.

The real kicker in Amazon’s design is that they use the thumbs up/down rating to juxtapose the most highly rated positive rating with the most highly rated negative rating. In effect, they create a top-level debate giving the best reasons for and against buying a product. What a clever bunch of designers they have working there.

I also don’t have the same issue with comparability that Kirtland and Schiff are citing. While positive and negative reviews of the same product will often discuss completely different criteria, it’s also implicit that they’re both rating the product as a whole. The reviews are helpful because they disambiguate the reasoning underlying the rating, giving the readers the opportunity to decide which criteria are most important to them.

Kirtland and Schiff’s article is a good piece, but I think it does a bit of a disservice to a very impressive social component.

Flash Design Heuristics

Flash presents a unique subset of design challenges and opportunities, many of which may be unfamiliar to a person who’s long worked in conventional Web UI’s.

I believe that design heuristics work better when they’re more focused to your design medium.  So I’ve put together a set of guidelines, below, to assist designers working with Flash-based applications.  I’ve done a fair amount of Flash design, and these are the principles that have helped me in the past.

Mirror well-established conventions
Avoid presenting interface elements in new ways when established conventions are available.  Rely most strongly on the conventions common to the web, followed by those common to desktop software.  Controls should support all the same behaviors in a Flash interface as they do elsewhere.

Allow user control over progress
The rate of progress should be controllable by the user at any point (outside of loading times).  Provide next and back buttons for serial progression.  Provide a timeline slider and other playback controls for video and audio.  Allow users to cancel self-running interface elements.

Error prevention
Minimize opportunities for the user to make an error.  Eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Readability
Ensure that onscreen text is adequately readable.  Do not anti-alias small fonts.  Bring animated text to a stop to allow users to read it.  Maximize the contrast between text and background.  Avoid overlaying text on busy images that can interfere with the appearance of lettering.

Passive comprehensibility
Users should be able to anticipate an object’s function simply by looking at it.  Users should not have to actively move the mouse cursor over a control to reveal its function.

Avoid downtime
Users have minimal tolerance for unproductive time when using the web.  Do not use splash animations.  Allow users to accomplish something while an application loads. 

Minimal requirement of mouse skill
Assume coarse mouse movement.  Do not punish users for using the mouse as they are accustomed in software.  Observe Fitts’ law.  Support keyboard input.

Provide actionable next steps
Don’t let the application come to a dead end.  If there is an end state, invite users to take next steps.  Allow them to review what they have already seen, modify parameters, provide feedback, link to related information, or access similar applications.  Keep the interaction alive.

Controlled use of animation
Use animation as primary content or to draw the eye to important elements of the interface, but avoid superfluous animations that are peripheral to the user experience.  Do not loop animations indefinitely.  Avoid using animations in a way that may make the interface resemble an advertisement.

Support accessibility
Ensure that users with disabilities can perform the same functions as those without.  Keep download times and processor-intensive operations within reasonable limits.  Computer speakers are often turned off or absent, so don’t rely strictly upon the audio channel to convey information.