The importance of usability in Mobile Geolocation games.

Mobile geolocation games are a hot topic right now. The popularity of the iPhone, the potential for geolocation in HTML5, the geographic API integration with Twitter, and the rise of games like Gowalla and Foursquare all point to a significant shift in people’s perceptions of the potential of geolocation. I’ve recently been involved in the design of a geolocation game, and have seen the potential of the medium, as well as the usability lessons which must not be forgotten when designing multiplayer games with location in mind.

Working in a small group at the University of Sussex, and in conjunction with the Brighton based mobile games company Locomatrix, we designed and prototyped a game that uses location as a game-play element. Unlike currently popular games, like Gowalla, we wanted the game to be immediate, and played as a short, fixed-term game, not an ongoing campaign. Hence, after evaluating several ideas, we developed a ‘Predator’ style game, where the players are hunted, and turned into hunters, until only one survivor remains.

Pretty much like Willy Wonka & The Chocolate Factory

Into every step of production of the game’s design we aimed to integrate usability and user experience tools. For example, the initial design of the game was based on a survey sent out to a group of prospective players, with their results collated to inform elements such as the game’s multiplayer element, objectives, and artistic style.

In the iterative prototype development cycle, user research was conducted. From the first paper prototypes, to the final JavaScript version of the game, real players were brought in, and asked to play the game. Their reactions and observations were noted by invigilators, and further developed through post-test questions. Hence, even before we had a playable version of the game, it was possible to test player’s reactions, and deal with problems earlier, rather than later, where they would cost a lot more time to resolve.

An early geolocation prototype

So what did we learn about mobile geolocation games? Exactly the same things that should be considered for any sort of product development.

We discovered the issue that was most crucial for the mobile geolocation game is considering the context in which the game will be used. The game we made was designed to be played outdoors, fast paced, and possible in a busy city. Hence the game’s interface needs to make this easy. We ended up with

• Very few buttons (one most of the time, a second one when you can tag a player)
• Large buttons (takes up half the screen)
• Audio cues associated with important activities, such as when the player is in danger, or when the can perform an action.

So, instead of having to stare at the screen all the time, the player is free to look at their surroundings, and only involve the phone when given an audio cue that they can act. They won’t need to hold their phones in front of their face as they play – crucial for not being mugged! And when they need to act, they can do so quickly and easily, not impeding the game-play.

The interface, which could have proved a huge barrier to a ‘fun’ game, has been minimised, as a consideration to the context in which the game is played. This was discovered as the optimal method through iterative prototypes and tests with users, and is heavily dependent on the type of game. A minimal interface may not be ideal for all applications (consider a first person shooter with one button), and yet the context of a geolocation game allowed it to succeed here.

So, what lessons could we take from the development of this game? More important than the discovery that outdoor mobile games work best with a minimal interface is the method used to make this discovery. Involving users brings advantages no matter what product is being made, or what stage production has reached. From the first paper prototypes, we could see the interface players preferred, and hence reduce development time and cost. The time ‘cost’ of involving users is greatly outweighed by the time it saves from redundant coding. And everyone can see the advantage of that!