One of the most common misconceptions about user experience design is that it is actually user interface design, or, as one of my former game directors seemed to believe, something that could simply be applied to a game after the fact. He used to say “we need some UX on that” or “put some UX on it”. What that meant, in effect, was that we (or I, since I was the sole UX designer at that point) was supposed to add UI to make the system understandable.

Here’s the thing.

If it exists in game, be it a feature, a system or a level, there is already a user experience associated with whatever aspect of the game it is. The likelihood of UX or UI designers being capable of improving that experience just by slapping a UI on it is probably not that high. If a system or feature or level has a bad user experience, a UI will most likely only be a band aid. Sometimes it may even make things worse.

Crafting a user experience means being there from the start, understanding the design and understanding the vision of the feature. It isn’t something you can – or should – add later. This probably doesn’t come as a surprise, but “later” usually means that there is already an experience but it needs help and fixing because are unable to understand it, it is inconsistent or it is unbalanced.

(Obviously in some cases it works fine, but those are not the times we’re asked to put UX on it.)

Solving these issues are easiest done by avoiding them in the first place. Allow UX and UI designers a seat at the table at the designs inception and most likely all the possible issues are solved before becoming issues.

Solving issues with player perception or player understanding of a feature or system may require a bit more work. The best thing to do in cases like that is to do careful usability tests focusing on what the player is supposed to understand and how the feature is preventing that understanding.

To do this, we must know the intent with the design, the goal of it and what the player is supposed to experience when playing. Sometimes this is clear, sometimes it isn’t. It all depends on how well the game designers have done their work. In all honesty, the reason a mechanic or feature is difficult to explain to a player is most often because the feature is too complex or because it is unclear even to the designer what the intent with the feature is. ¹

A too complex feature can be simplified to gain usability and understanding. To be honest, this is usually what needs to happen anyway. The complex features are often – though not always – the result of a bunch of hypothesising around a system and how that system will be received before actually testing it out. Hypothesizing is one of the more insidious paths a game designer can walk down.

1. I’m going to be a bit pointed here and say that on occasion game direction will want to add a feature for the simple reason that they’ve seen it in another game and want to put it in theirs. Most of the time when this happens, there’s an understanding around what the feature should bring, to the game, and this is made clear to the designer tasked with adding it. Some of the time, however, the directive to add a feature is unclear on the “why”, with the result of having the feature also be unclear on the why and what the intent was. I am, of course, of the opinion that if you intend to copy a feature, know why you’re copying it and what the gains are. Unless it is your own game that you’re making for yourself in your home office, “because I like it” does not cut it.