Let's look at some examples of how one or more of the steps could fail if the simple menu in this example had been designed incorrectly:

Problems in Stages 1 and 2: I once ran across a game that had its sound control labeled as simply "SFX." In the game industry we often abbreviate the term "sound effects" in this way, but what if the player is not in the industry or if he interpreted it to instead mean something else, such as "special effects"?

During a play test I observed a user open this menu, examine it for a few seconds, and then ask me what "SFX" meant! This was a failure on the part of the menu's design, because bad labeling of the sound control was thwarting the player on Stage 1; without a good label for the sound control, he could not form the goal to "change the sound volume."

If the player had come to this menu already armed with the goal of "change the sound volume" then he would have been stuck on Stage 2; how could he form the intention of manipulating one of the controls to lower the sound, if none were clearly associated with that task?

Problems in Stage 3: If a control is inadequately designed, it may be difficult or impossible for the player to determine what to do with it. I remember once seeing a horizontal slider control labeled "Sound".

But it didn't have any indication about which way to slide it to increase the volume and which way to decrease the volume[1], or even whether "volume" was indeed the property being controlled (it could just as easily have controlled the sound's left/right panning).

Without something to visually indicate which way is "more" and which way is "less," the player may have a hard time completing Stage 3: Specify the action with the ease we should expect from such a simple operation.

Problems in Stage 4: Once a user figures out what to do with a control, there are still several obstacles that could give him trouble with Stage 4: Execute the action. A few real-world examples might include:

• If the user prefers the keyboard but the control only accepts mouse input
• If the user has a wide finger and the control is too small and too close to other controls, on a touch screen
• If the user has a disability and the control doesn't support adequate accessibility options
• If the control doesn't provide as much precision as the user would like (e.g. the user wants to increase by three, but the control only lets him increase by increments of ten)

Problems in Stages 5 and 6: It's common for controls to fail to give user feedback (a problem at Stage 5), or to give feedback that's unclear or confusing (a problem at Stage 6). In our Settings menu example, what if the volume control didn't play a snippet of sound after the slider was moved?

The player might be able to visually see that the volume is decreased, but without the audio sample he'd have to go back into the game to find out whether he was satisfied with the new volume.

Even our well-designed example menu could be slightly inadequate: if the menu's audile feedback was to play the sound of a gunshot, for instance, then the player could only guess at the new relative volume of the explosions.

Results in Stage 7: By the time the player is at Stage 7: Evaluate the outcome, there's not much you can do for him; either he, and therefore you as a designer, have succeeded or failed.

Whatever the interaction, make sure you've allowed for good results in the prior steps so your user will perceive a success. If he perceives a failure, then be sure to make it clear to him why he's failed and indicate what he can do to correct the situation.

[1] Cultures that read from left-to-right might naturally associate "right" with "more", but if the menu were localized into a right-to-left language then the intuitiveness afforded by this cultural standard would no longer be helpful.