I believe that the key differences are:
- In game UIs, you can occasionally justify putting aesthetics before function
- Games often require rapid user response
- Even turn-based games usually limit the time available to a player
- Psychologically, the fact that games you usually volunteer to play probably makes a difference
![]() |
| Tetrablok sea UI draft |
It is my firm belief that when designing game UIs you can, occasionally, put aesthetics before function. Emphasis on the word occasionally. Your UI should be designed to, first and foremost, be functional. Frustrating but pretty UIs are just – here comes the pun – pretty frustrating. It comes down to, or so I believe, to psychology. In games, you occasionally expect fireworks and you are more likely to forgive slight usability issues in favour of aesthetically pleasing presentation. Microsoft Excel (okay, pre-ribbon Excel anyway) is a great tool with a pretty slick UI and yet most people would agree that they expect something different from games. In a game, I can often justify placing a button in a sub-optimal position to make room for pretty pictures. Often, you will choose to display numerical attributes in non-numeric form (e.g. progress bar, pie chart) just because it looks prettier. Occasionally the graphical presentation adds value and makes the attribute easier to comprehend. Sometimes it just looks better. I could go on.
The second point, which I’ve strangely decided to elaborate on last, is probably the most self-evident. Many games require fast reflexes and in-a-fraction-of-a-second decision making. Please, allow me to put aside the whole topic of game controllers. Also allow me to ignore the very extremes of fast-pacedness – FPSs and the likes. Controlling your character in FPS games is more about the controller than the UI. Ditto for most games where shortcut keys are the primary interaction method. Game controllers are a fascinating topic but I will stick to UIs for now.
Now that I have conveniently (if somewhat cravenly) narrowed down the gamut
of game UIs to consider, we can pit games against productivity apps. If I am
permitted to rule out a few games more, let’s assume there is a time
constraint of some type embedded in the game mechanics. In Seepia Games’
games, the constraint is usually time per turn. The time constraint has a
number of functions: it forces the player to work his brain more intensely,
it can be used to control the maximum duration of a match and, perhaps most
importantly, it protects the opposing player from dissatisfactory ennui. This
sort of artificial time constraint rarely exists in the realm of productivity
apps. High pass-through rate (completion of a form, process etc.) is
desirable but I cannot think of many scenarios where it would make sense to
impose a time limit on the user. Such limit could even backfire causing
stress and lowering productivity.The question then becomes, are games and productivity apps different after all in this sense? Prompt, precise response is the desired user interaction either way. Games simply add a “sweat factor” – the time limit. Therefore, I am happy to accept that the chasm between the two is not that wide after all.
So, I posit that a good game UI looks good but still follows the usual principles of good UX design: it works with the user, not against him; it stays out of the user’s way and lets the user focus on the fun parts; and finally, it excites the senses and tingles the bits of your brain that appreciate aesthetics.
There is one more aspect to this I have not discussed now but to which I may return in future – learning curve. A topic for future post, perhaps.

No comments:
Post a Comment