As you may know, I wrote my honors thesis on Human Computer Interaction back in my university days, and since then have done a lot of UX and UI based work over the years. I thought I would share some insight into some common things that people mistake UX for UI and vice versa. So here is a clarification post for those interested.
Normally, we think of the term user interface (or UI) as it applies to applications. Technically, this term refers to the parts of the software which interact directly with a human. So, it covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). For example, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).
In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.
What makes one UI better than another? We generally talk of two things:
• Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?
• Ease-of-learning. If you are new to the screen, how easy is it to figure out what you are allowed to do and what information is available to you?
In usability theory, there are two related concepts: the “user model” and the “program model”. The user model is how the user (i.e. the player) thinks that things should work.
The program model is how the software actually works. You can think of the “program model” as the actual rules, and the user model is what the players think the rules are. Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the user is going to do something, they’ll expect one thing to happen, but another thing happens instead. Now, with things like computer games, this leads to frustration, and the users will say that the game has “poor play control” (often
without fully understanding why).
So, by giving your solution a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.
There are many great books on UI design. If this topic interests you, I would recommend Donald Norman’s Design of Everyday Things, which gets into the details of how the design of something as simple as a door or a stove can go horribly wrong… with lessons that can be applied directly to games, both digital and non. Also, for ways to show game data to players in efficient and innovative ways, I would recommend any of Edward Tufte’s books: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.
Campbell Craig 