« Unsanctioned Advergaming Appears In WoW | Main | NYTimes Tracks Down Gold Farmers »

Dec 07, 2005



Before I was in the games industry I was a user interface designer and user-centered design (UCD) consultant. Among other places, you can see my work on GE CT scanners, HP defibrillators (in airports and such), and even on touchscreens for some Xerox copiers. In many ways this was compelling work -- for example I designed the UI for the first 3D graphical display used by surgeons in the operating room (and the first time I got to see it being used was on a 5yo girl with a deep brain tumor that was inoperable without our navigational tools).

Oddly enough though, games are more compelling to me. I think this has to do with an essential difference between games and other forms of software: games have no external "task" associated with them. One of the main aspects of UCD is doing some form of "task analysis." You want to know who the users are (personas, etc.), what their environment is, who is making the buying decision, etc., but ultimately what's key is what is the user trying to get done. In typical software, you're trying to replicate, automate, or augment some externally existing set of tasks; rarely are you creating brand new tasks that don't refer to something existing outside the software. UCD can be a huge help in refining the development team's understanding of the users' psychology, culture, informational load, and how to make the tools you're creating best conform to their goals and tasks.

In games, we don't have this task-based foundation. A central (if typically amorphous) part of game design is figuring out what the player will be doing and why -- the scope of their goal/task set. Moreover, since the game has no external utility (it's not "good for something" in the outside world), and since no one is compelled to play a game, the tasks and the users' approach to them have to be inherently attractive and compelling -- what we typically roll together as "fun." If they're not, people won't play the game, and it fails as a product (contrast this with software tools or products that people use because they must, no matter how aggravating they are).

What this means to me is that game developers more than anyone else should be acutely aware of UCD principles and be applying them in game development. The trick there, again, is that you can't sit down and do a task analysis with a potential player; you have to first define the goals and tasks, and iteratively hone them until they are sufficiently approachable, engaging, and challenging. Traditional UCD methods aren't sufficient for this, but I believe they are a necessary component.

Unfortunately, I don't see UCD techniques being applied in game development much. Some places use end-of-the-line usability testing (EA used to call this "Kleenex testing"), and focus groups have been as misapplied in games as in any industry. But I see little emphasis on (or interest in) viewing the game as a set of goals, tasks, and tools that can be iteratively refined to create something fun. That seems to threaten being too clinical, too paint-by-numbers for most developers.

Years ago at SIGCHI Randy Pausch made the point that games often lead the way in UI development because they are so evolutionarily stressed: no one has to play your game and it doesn't really do anything for them, so it had better be good. If it's not, the players will move on to something else. This creates an environment that is highly competitive and often highly mutative -- and thus, highly evolutionary. In such an environment, it makes sense to me to bring all the tools to bear that you can to increase your chance of success. UCD -- or as TL has said it here, "Player-centered design" -- is IMO one of the strongest set of principles and methods that can be used to do this.


You know, I haven't gotten the hang of this whole trackback thing yet, because I feel like I want to write giant responses on my blog, but then I wonder if they'll get left out of the conversation here. :) So, follow the link to get my fuller thoughts. (oh, and btw, can we change the links to my site on the sidebar there? They point to the old site).

But my real reason is to comment on Mike's reply... I agree as to the huge vaue of traditional UCD, but as you note, it's far from being the whole picture. I disagree with Randy Pausch, for example, that game UIs have really proven to be so spectacular; one only has to look at the near total rigidity in UIs in established genres to see that. So much of gameplay is playing the UI that players are reluctant to play a familiar game with a different control scheme, even though it might actually improve the game. Given MMO history, one could even argue that fresh creativity in UI design didn't really get embraced until it got taken away from designers altogether and put in the hands of players via UI modding. Talk about more player-centered...

The thing that UCD doesn't give you is "figuring out what the player will be doing and why -- the scope of their goal/task set" and yet, that's what the game industry seems to keep trying to apply crude player-centered design to.


Wouldn't the ultimate UI be one that was entirely player created and modded? WoW, when modded with some amazingly well done addons, can have the perfect UI for you as an individual. While there are always complaints about what Blizzard has done, making the UI accessible to add-ons by design was brilliant.

They should certainly take better care to avoid breaking all add-ons with major patches, so there are lessons to be learned from them, but I don't think I could ever play a game of that type that DIDN'T let me have my own UI.

Of course you can't do this with every type of game, and yes, the basic UI has to be good, because not everyone is going to mod it. But the ultimate PCD is to let the players do it themselves. Then, as Blizz does, "steal" those mods by incorporating the favorites back into the core UI.

Would it be feasible to design the alpha and beta tests of most games to have a highly flexible, user configurable interface? Then use the most popular configurations in the final product? That is probably idealistic, but the concept is pretty compelling.


I don't know enough details or nuances of how graphical things work to say anything about it, but in textual, all you really need is an XML document as the message to the client about what you can see.

If you build a client that parses the XML and throws it up as a pretty useful thing...


First of all, I want to thank TL for the nice words concerning our work. It is obvious that I find it fascinating but you can never be too sure if other people do.
Our approach
(PDF link) is designed to shed light on the fuzzy-front-end of the design process. As our experience and the discussion here shows other kinds of methods have to be used in other phases of the process. Have to go now, I will continue once I have the time.

The comments to this entry are closed.