One of my fav things to do when creating UX design for games are mockups. Mockups are both fun and communicative, and they’re the precursor to actually implementing things in the game. When I start making mockups, I also get a feeling for what interactions that I’m missing and what interactions are needed to communicate what I need for the game.

It might be anything from how messages and notifications are displayed to how damage is communicated – if you put it on screen in a mockup, you can often tell what needs to be done to complete a loop or make sure all the interactions you need are there.

UX design isn’t so much about straightforward screens and messages as it is about exceptions and edge cases. If you can find most of the edge cases, you can also plan for most of the ordinary interactions. Edge cases are the instances where the player does things that they’re really not supposed to do, but that they can do and that the game has to take into account. Usually, finding edge cases is tricky, because it requires you to think not only of what the game should do, but how actions can backfire.

This is a really old mockup from a very early version of the game Mad Max.

What happens, for instance, if you’re out looting and your backpack is full? That would depend on what type of backpack you have, how many spaces you’ve got, if there’s a limited or an unlimited amount of things you can pack into it, what kind of things you can pick up, if you have options when picking things up (apart from “pick up” and “don’t pick up”) plus a ton of other design decisions that make up the design loops for the game. Diablo III is a loot fest, but the first version of the loot in Diablo III wasn’t great. Along comes Loot 2.0.

These kind of decisions make a real impact on the UI. Compare with a game like Alan Wake and you’ll get a completely different loop and a different UI, because in Alan Wake the game is not driven by loot so much as consumables such as ammo and batteries. This puts other requirements on the UI.

Making mockups can also be about making sure that the systems behind the UIs are simple enough to understand. If the underlying systems are too complex, perhaps the player won’t understand them? It might require simplifications, changes and iterations. It’s actually not unheard of that the UIs sometimes drive the design, or at least push it in certain directions. For the UX designer, the challenge is to make game mechanics transparent enough to the player that the player understands them without reducing the game loops too much. We have to pick up the important information and make sure the player can see it. In other words, as in the loot 2.0 video, the UIs can actually have an impact on the systems, or perhaps on how the systems are shaped.

For me, mockups are about making sure that I’ve considered most edge cases and most oddities that can occur in a game. There’s no way to account for everything, but with mockups I can account for most things, and I can also determine if a feature simply requires too much information to be viewed on screen. The first mockup is usually not the screen implemented in the game, rather the first mockup is just getting all the features on there. Iterating gradually streamlines the design to make it more and more refined until you end up with something quite different in the final game.

For me, seeing a really busy screen end up being a simple button prompt is a victory. The fewer moving parts included in a UI, the better, because the fewer components a game consists of, the less the player can misunderstand.

As a UX designer there is one thing I can always be certain of. No matter how obvious I think I’m being in my designs, someone is always going to completely fail grasping what the heck it was really about. Mockups help me reduce the number of failing players.