In the my earlier post, I talked about Jesse Schell‘s book, “The Art of Game Design”, promising to go lens by lens through the book. This is the first post looking at a lens. More to come!

Jesse Schell’s Lens #1 in The Art of Game Design is “The Lens of Essential Experience”. This lens is about the experience of the player playing the game.

[pullquote]
The Lens of Essential Experience
To use this lens, stop thinking about your game, and start thinking about the experience of the player. Ask yourself these questions:

• What experience do I want the player to have?
• What is essential to the experience?
• How can my game capture that essence?

— From The Art of Game Design: A Deck of Lenses
[/pullquote]

From a game standpoint, the experience of playing is the main reason for the existence of most games. Games aren’t generally trying to solve a problem – they exist because the players want to have fun. In the broader world of software systems, there is generally a problem the system we’re testing is designed to solve. That problem might be making some process (like tracking finances or managing orders) more efficient or it might be any number of other things for a particular user base. Even when the goal of the software is something other than the experience of using it, however, the experience a user has makes a big difference on how they perceive the application. We’ve all likely had the experience of using software with a poor interface, and it’s unlikely that we see that system of being of high quality, particularly when compared to systems that are easy to use.

This lens invites us to look at our system from the perspective of that end-user. It moves us away from determining whether each feature works the way it should in isolation and focuses us on the solution that the software is providing and how the user will interact with our system. Think about the tasks that a user will be trying to carry out. Will the software make it easy for them to achieve their goals?

One aspect of this is the straightforwardness of the action. Extraneous clicks and dialogs or hidden interface elements can lead to frustrated users. For example, at the beginning of 2013, my company gave each employee a Surface RT tablet. This was the first time I’d encountered the Windows 8/RT interface and I didn’t know that swiping in from the sides of the screen would bring up toolbars and options. I was initially frustrated that simple actions like Searching or even finding settings for the apps I was trying weren’t available. It was only after searching online for how to accomplish a task that I found how to access the charms. Until I learned that, my user experience was lacking.

On the other hand, making actions too easy to access can also cause problems. Some apps put the button to delete an item near other non-delete buttons and a misguided click (or tap on a mobile device) can result in the user losing work. I ran into this recently as well, when I was checking out at a grocery store. The checker misremembered the code for onions and entered the code for cucumbers instead. In trying to fix the issue, he ended up voiding the entire transaction (seemingly without confirmation that he wanted to do that) and had to rescan every item. Neither he nor I were fond of that user experience.

There aren’t rules to guide every experience. Testing the experience our software creates requires us to think about how a user will interact with our system, to put ourselves in their shoes. It involves recognizing the things the user will want to easily do and enabling those things while preventing (or restricting) the things that will get in the way of those tasks. It involves thinking about the emotions we want to invoke in our users and understanding the essentials of those emotions. We may want to delight our users when they find we anticipated their needs in unexpected ways or we may want to make a task as efficient as possible to let the user do their task quickly and get on with the rest of their work. Whatever our goal is for our experience, we can use the Lens of Essential Experience to focus our testing on determining whether we have met that goal.