Usability and Game Design

Most usability experts will agree, Dr. Donald Norman’s book “The Design of Everyday Things” is required reading for any aspiring user experience or product designer.

But it’s also an excellent resource for game creators – even if it’s less commonly found on studio bookshelves.

In this slim volume, Dr. Norman elegantly explores human perception, cognition and decision-making in a highly readable and broadly accessible style.  To illustrate basic models of cognitive processing, Norman picks apart the most seemingly mundane human chores: opening doors, dialing telephones and setting refrigerator temperatures.  Purposefully, Norman sets these simple examples firmly in the “real world,” implicitly and critically arguing the universal nature of problems facing usability designers.

Norman proposes that human interaction can be broken down into a sequence of stages – the “Seven Stages of Action” - and suggests that designers can interrogate their own designs based on user needs at each of these stages by asking:

How easily can a person…

•             Determine the function of a device?
  
•             Tell what actions are possible?
  
•             Determine mapping from intention to physical movement?
  
•             Perform the action?
  
•             Tell if system is in desired state?
  
•             Determine mapping from system state to interpretation?
  
•             Tell what state the system is in?           

The questions are perfectly suited for examining the implementation of your game design.  Addressing these questions can have a direct impact on your game’s appeal, controls, usability, fun and “feel.”

The feature set of the iPhone and iPod touch offers exciting new options for adressing some of these challenges.  Let’s take a look at some of Norman’s questions in the context of design your game:

How easily can someone…

Determine the function of the device (i.e. your game)?

One might describe success here as having good “pick up and play” – that is, someone unfamiliar with your game mechanics can understand how to interact with your game quickly. 

When publishing on the App Store this is a particularly critical question: consider that first minute of experience carefully – you are competing for player attention in a broad sea of games, and if a player doesn’t understand your game quickly there is a high risk that player will move on to another game.

Tell what actions are possible?

Training is often left until late in design, but successful games take training design seriously.  

Tutorial messaging can help teach players about your game mechanics, but don’t rely on text or UI explanation as the only means of training your players. Many users will dismiss dialogs quickly or not retain information delivered through UI and text alone. 

One alternative is to allow “safe” experimentation with your game early on: instead of explaining the mechanics with words or static images, consider an interactive training sequence designed to teach allowed actions by guiding players through game-like situations. 

Interactive training satisfies player curiosity and encourages exploration of your game.  It also allows players to perform actions incorrectly without punishment.  Well designed training can keep players engaged and entertained during those critical first moments of play.

Determine mapping from intention to physical movement?

Are your controls “natural?”

Consider what players are likely to try intuitively and weight natural player inclination accordingly in your control scheme. 

If you don’t know what they will try first, give your prototype to a few people without explaining the controls and see if they naturally want to touch, tap or tilt to interact, and then consider how you can take advantage of that natural inclination in your control, UI, art or training design. 

Perform the action?

How well are you executing your controls? Is the button big enough and bright enough?  Does the UI obscure key gameplay information?  Is the framerate high enough that touch events catch every player input?  Do you handle “accidental” input like dragging off the screen? 

Tell if system is in desired state?

Satisfying play often takes care to communicate “success” in the midst of play.

That is to say, don’t count on a “You win!” screen at the end of the level to tell the player that she successfully performed the actions required to succeed in your game. 

Consider how to create micro-feedback during gameplay with proportional player “payoff” for successful actions. 

For example: did the player successfully equip the tank with heavy artillery cannons?  Let them know with a CHA-CHUNK sound effect and beefed-up art on the barrel.  This may seem obvious — but consistent, thorough examination of all your interaction for feedback like this is critical to delivering a highly polished, satisfying play experience.

Determine mapping from system state to interpretation?

Put simply: does the player understand that their action directly affected the game’s state? 

Closing the mental loop of “user forming an intention” -> “user interacting with a system to execute on that intention” -> “user understanding the result of that interaction” -> “user forming a new intention” is at the core of Norman’s model of interaction, and designers should think of it as a game loop that always needs to be closed.  Doing so can build player learning. 

“I intended to upgrade my tank – I touched the ‘upgrade’ button in an attempt to do so, and the subsequent sound effect and barrel art change must mean that the upgrade succeeded.  And now I can upgrade the treads in a similar way.”

Tell what state the system is in?

In general, does the player always understand what’s happening and how to make something else happen? 

You may love the elegant design of your subtle “pause” text at the lower left of the screen, but if the player has paused the game accidently and doesn’t see that text she may think the game has crashed. 

Clear feedback of system state– at all stages of interaction – is one of Norman’s most inviolable lessons.

I’ve kept these rules pinned on the wall at my desk for years and often photocopied the page from the book  (page 53!) for other developers.  If you have your own “checklists” for design, let me know.

Matt Roberts

matt [at] ngmoco [dot] com