Short form: UX design is about removing problems from the user. Game design is about giving problems to the user.
In both cases you look at users’ cognitive reasoning and process capacity. And these days, we have UX designers on game teams, and they are incredibly valuable. But they are in a different discipline from game design.
Most UX designers don’t work in games. They work in website design or application software. They focus almost entirely on interfaces. In general, a UX designer’s job is to create a great experience when using something for a purpose. They therefore do as much as possible to make the interface
- transparent, so that the user needs to think as little as possible
- affordant, so that the user knows what possibilities it offers
- scalable, so that it unfolds as the user develops skills
- feedback-rich, so that the user knows when they did something
- constraining, so that the user can’t do things that get them in trouble
What they do not do is
- actually specify the inner workings of whatever is being used. They are usually working to provide an experience to a system already designed by an engineer, or specifying an interface to a system that an engineer will then go design.
- make interfaces revelatory of the inner workings of the tool. Usually, we don’t want you thinking too much about car guts or lexical parsers when driving or using a word processor.
UX design in non-game applications is absolutely not about teaching the player how the guts of the software works. It’s about getting them to build a mental model that helps them get their work done. Classic examples might be the steering wheel of a car, or the entire desktop metaphor. The steering wheel is actively hiding from the user the fact that there’s a pretty complex mechanism in between the wheel and the tires. It’s instead trying to get the user to think “turn the wheel, turn the car.” This is an intentional elision of most of the actual workings of the steering mechanism. Similarly, the desktop metaphor in operating systems is intentionally trying to hide quite a lot of stuff about how the file system actually works, in order to build a consistent skeumorphic metaphor in the user’s mind, one that ties back to known cognitive patterns and is therefore easily understood.
In general a game designer’s job is to create a great experience when playing a game. They therefore do as much as possible to make the game
- challenging. Often, we want the game to make the user think a lot.
- explorable. We usually want the user to think there are always more possibilities in there.
- scalable, so that players learn better play as they play.
- crazy juicy, so that players are captivated by spectacle, well beyond the needs of feedback from a UX perspective
- inviting of error. We want players to learn through mistakes.
In addition, game designers
- typically do specify the inner workings of what is being used — not just the interfaces, but data structures, algorithms, formulas, and so on (often indirectly; it may be the gameplay engineer who writes the technical spec). They are intentionally creating a problem-rich environment.
- are trying very hard to make the game experience revelatory of some of the inner workings of the game. Where UX tries to provide a likely false but useful mental model of the interior workings to the user, game design tries to guide the player towards a fairly accurate mental model.
In general, these lines get blurry. We want the way to fire your gun in the wrong direction to be as transparent as possible, so in games we try to layer great UX design on top of something that is in fact the opposite.
In game design, you’re usually trying to give players an understanding of the “machine” inside the game system. Typically, you have an interface to the game system that does in fact follow traditional UX principles: for example, moving the mouse to the edge of the screen resulting in panning a camera. That’s pretty traditional UX for an RTS. But understanding things like the overall build rates of different types of structures, so that the player ends up mastering complex supply chains and dependencies — not only is that a piece of game system design, but the intent is to get the player to actually understand supply chains. A UX approach would hide supply chains (as in fact they are hidden from our shopping experience).
UX is about clarity that hides complexity, and game design is about clarity that teaches complexity.
These days, we see UX designers who work designing UX at the game systems level. Until game teams got big enough, that’s how all designers were. 🙂 The splitting off of UX as a separate discipline that an individual performs on a game team is a result of large teams. Originally, we just had “game developer.” As teams grew and specialization started occurring, first we got content designers, then UI designers, and now we have UX designers. (I remember when designers at Origin were just called “technical design assistants.”)
Historically, though, ownership of the overall UX has fallen to whoever the game’s “director” is, who ideally is someone who has a solid grasp of every subdiscipline in the game design field; enough to manage people who are more expert than they, anyway.