Lessons from game design

Tutorials, welcome screens, help messages… in my opinion we’re experiencing an unnecessary abuse of them. Despite their utility, they’re misused, trying to present the full power of our wonderful software and explain how to use it. It's easy to do that and forget the users, blaming them for not reading the instructions.

For this reason I’m interested in talking about games. Why games? The process of game design faces similar design problems to those we face every day, but because of their nature, games have some practices that can change the way we approach interaction design.

All games have a goal and a series of rules and mechanics that the player must follow to achieve it. In the case of interaction design, the user has his or her own story and motivation, and we should model our system so the users can accomplish their goals using techniques similar those found in games.

 

Lesson 1: Complete the goal easily

Users should be able to achieve their goals as simply and as easily as possible. Making this happen is one of the reasons why we're hired. Usually, in the gaming world, the player has a small set of mechanics that can be combined (let’s say jump & move, for example) to aid him/her in reaching the goal. At various points in time, we can introduce new mechanics to interact with a new obstacle, as appropriate. With this in mind, our world of software design needs to present as few elements as needed, and let the user “play”, combining them to accomplish the tasks at hand. We should only add new mechanics if the task requires it.

But how do we introduce these mechanics without intruding on the experience (aka displaying a tutorial)? A good game design crafts its constraints wisely, to teach the players what they can and can't do. Even the story, if present, needs to be written to support this purpose.

To accomplish this we must put ourselves in our user’s story, in order to understand their motivations and goals. By employing our UX toolset (research, analytics, competitive analysis, etc.) we can know what users are trying to accomplish.

If a screen is well designed it will also explain its purpose, so the user knows if he or she is traveling on the right path in their adventure or if the path needs to change in order for them to succeed. As you recall, the approach is to provide only the information necessary to understand the environment and what can be done at each point. This could be done with text, telling the user where they are, where they came from and where they can go. But text is not the only tool we have. We must remember...

 

Lesson 2: Give high value to the aesthetic experience

Text, visuals, animation, sound, vibration are all available to provide the user with information. The richer and more uniform we make this experience, the clearer each on-screen element’s purpose becomes to the user. Both game players and software users get involved in the universe we create using the language we’ve defined. Remember, every element and bit of context is part of the user experience, even if we didn’t intend it to be.

 

Lesson 3: The final experience is a whole story

You could start designing a specific feature or mechanic, a specific part of the story. But to understand if it works you need the whole story.

In a game this is clear and noticeable, but in software it may not be as obvious. It’s good practice, therefore, to start thinking about the whole story and craft “the world” roughly (but with enough detail to feel and understand the experience), instead of crafting to perfection small sections. By working in this way, it’s going to be easier for someone outside the project to understand your ideas and “feel” the experience. If you focus on the small details first, it's likely that you’ll miss an important part of the larger “story”. Rather than a good experience it will just look like a promising, if disjointed, idea.

 

Lesson 4: Fail fast (and accept it)

The process of creating a game is long, involves a lot of work and experimentation of ideas that will never be included. But it’s done to learn, to know the limits of an idea, what works and what does not work for our users. The quicker we discover what´s wrong, the more time we have to improve it. But what happens to this great idea that I have for a particular feature? “Doesn't work well with the rest of the experience, but it’s great…” Just save it for another time and think of a solution that blends with the rest of the experience. Remember that giving a unique, well-cooked experience to the user is vital. If you create different micro experiences without any reason and connection... It’s just not going to work.

But also remember that you’re the one that has the vision and knows the rationale behind the design.

And you are the one that knows what you are testing. Listen to the comments you get, but more importantly, understand why the users are making them, understand the problems more than the solutions that they propose. The vision is the most important thing, so if you need more time to do it well , take it. Fail fast, but not too fast.

 

Lesson 5: Give additional value to users who “experiment”

If we can agree that users should be able to complete most of their usual tasks with only some basic rules (or mechanics), it is worth reminding designers that users who decide to invest more of their time in order to explore the software and try new paths, should be given more functionality or, perhaps, new abilities, like shortcuts. The point is to reward users by providing experiences of additional value, rather than trying to convince ourselves that a better understanding of the application is its own reward. After all, no gamer would ever believe that!