Page 1 of 5
[In a detailed design article, Griptonite Games' Jason Bay uses classic usability concepts to break down the gamer's use of in-game weapons, objects, and puzzles, suggesting how this can make everyone build better video games.]
A designer's most important job is to craft unique and interesting challenges for the player. Too often though, we discover that players are unexpectedly challenged by aspects that should be easy or even invisible during gameplay.
These might be the workings of the user interface, or an in-world interaction that should be a snap to figure out but somehow just isn't. When these things get in the way of normal progress, players become frustrated and can stop playing your game altogether.
As developers, we try to discover these problems early and rework the objects in question until they approach a better semblance of usability. But the journey from "this sucks" to "hell yeah!" can take a lot of work and iteration and the goal is often reached more through intuition than on established process.
Rather than running on gut instinct, we could benefit from a reliable method of understanding of how players interact with the game so we can consistently predict potential problems and adjust accordingly -- before the game ships.
In classic usability book The Psychology of Everyday Things, author Donald A. Norman describes a system of assessing the usability of objects by examining the psychology behind how people perform tasks. Although his discussion is oriented for real-world objects like doors and clock radios, we can apply his methods to our game worlds to find out whether each game object is truly intuitive and easy for the player to learn and use.
In this article, we'll examine how this idea can be applied to build more intuitive (or more challenging!) objects, puzzles, GUI controls and other game world interactions.
Norman defines that each person goes through seven stages of action when using an object, from the time he forms his goal to the time he evaluates whether he's successfully accomplished it:
Stage 1: Form the goal
Stage 2: Form the intention
Stage 3: Specify the action
Stage 4: Execute the action
Stage 5: Perceive the state of the world
Stage 6: Interpret the state of the world
Stage 7: Evaluate the outcome
You can assess the usability of any game entity by mentally walking through this list, in order, and examining whether it's possible for a player to engage in each step. If it seems like a player won't be able to perform one or more of the steps, then that's a red flag indicating a usability problem you should address before your design is perfected. Conversely, you can intentionally omit a step in order to create interesting challenges for the player depending on which one you leave out.
To help illustrate how you can check these stages to analyze a game entity's ease-of-use, let's run through a simple example. Let's say a player thinks the in-game explosions are too loud (he likes 'em loud, but he's at risk of waking his daughter who's sleeping in the next room). If we were to analyze the game's Settings menu, what sorts of things might this player be doing or thinking during each stage of the action?
1. Form the goal: This is the stage where the user forms the overarching end-goal they'd like to accomplish. "Here's the Settings menu. That seems likely to offer an option to lower the volume of the explosions."
2. Form the intention: In this stage, the user starts to drill down on how they could go about advancing toward the goal. "There's a control labeled 'Effects' -- I'll bet I can manipulate it in some way to affect the explosion sounds."
3. Specify the action: During this stage the user identifies specific actions that can be taken. "The 'Effects' control looks like a little handle on a horizontal track -- it looks like I could grab the handle and drag it along the track to change the volume. The right side of the rail has the icon of a large speaker and the left side has the icon of a smaller speaker, so I'll drag it to the left to decrease the volume."
4. Execute the action: (He grabs the little handle with his pointer and moves it along the track to the left.)
5. Perceive the state of the world: In this stage, the user first experiences any feedback that resulted from his change to the system. "I've dragged the handle to the left and then released it there. The game played a sample sound effect."
6. Interpret the state of the world: This is where the user interprets the meaning of the feedback he received in the previous step. "Now the handle is closer to the icon of the smaller speaker and the sample sound seemed to be quieter than what I heard in-game before I moved the handle, which probably means that the explosions will also be quieter."
7. Evaluate the outcome: "I wanted to turn down the sound volume, and that's what I did. Success!"
A typical user would move through these stages subconsciously in a couple of seconds, but if he isn't able to smoothly move through each and every one then it can lead to confusion or frustration. It's your job to make sure that doesn't happen.
Page 1 of 5
