03-31-2011, 05:39 PM
'Tis easy to talk about "the player" when talking about creating user interfaces for games. I end up doing it myself, even though I know better. There ain't no such animal.
Grim pointed out, in another thread, that sometimes programmers design the game assuming that the players have the same degree and depth of understanding of every aspect of the game as they (the designers) do. And Grim is right. That is a big fail.
There is a tendency among some interface designers to go to the opposite extreme. To design the game to be "user friendly," by constantly pestering the player with requirement that he agrees that he understands the consequences of the order he has given. As one mentor of mine said: can you imagine having a human assistant who constantly said, "Are you sure you want to do this sir?" every time you told him-her to do something? That can get old, quite quickly, even for a noob, and is about as friendly as a straight-jacket.
What designers (and critics of designers) need to understand is that there are a whole bunch of different types of users and the interface has to work for all of them - which sometimes means having more than one interface, not designing for the lowest common denominator. When looking at an interface, it is important to have at least four or five personae and look at the interface from the point of view of each one of them. If Sally Mae Noob can't figure out what to do, it doesn't matter of Harry Curmudgeon likes it or Billy Whizkid finds it perfectly suited to the fact that he has memorized all 372 item codes. The standard questions that must be asked about the personae are:
Speaking of needs, research has shown that when someone approaches any new software, the most important thing to them is not looking stupid. Even if they are alone, that is the fear that a majority of new users experience.
The goal is to provide for the needs of all your potential users, adapting Web technology to their expectations and never requiring readers to conform to an interface that places unnecessary obstacles in their paths.
The user interface for a Web site should follow the general navigation and layout conventions of major Web sites because users will already be used to those conventions. Users spend most of their time on other sites not on the game's, so we should avoid highly unusual interfaces if the idea is to attract and keep a large audience instead of conducting a seminar for 12 interested people on alternative methods of navigating the Web.
A large part of good webdesign is making sure the player knows where he-she is on the website - and therefore knows how to get to everywhere else in the website. Important entry points (the home page, for instance) need to be reachable from everywhere. There should be no need to search for links to those points. Web design should offer constant visual and functional confirmation of the user's whereabouts and options, via graphic design, navigation buttons, or uniformly placed hypertext links.
One way of providing an interface for a skilled and frequent user is to provide keyboard shortcuts. Tapping <alt> <T> rather than having to switch back to the mouse, figuring out where on the page the cursor is and sliding it over to the proper button, menu, or link and then clicking it is a faster and more efficient method of getting to the "Transfer" page. Power users will appreciate it, while newcomers will never even think about it.
The best information designs are never noticed. Two excellent models of interface design are Adobe's and Amazon's websites. Graphic headers act as navigation aids and are consistently applied across every page in the site. Once you know where the standard links are on the page header graphics, the interface becomes almost invisible and navigation is easy.
Help documentation should be always available and specific, at least to the page, if not to the action about to be dealt with. Following a link to a help page should never mean losing any work in progress. There are 5 kinds of help that users want:
1. Goal-oriented: "What kinds of things can I do?"
2. Descriptive: "What is this? What does this do?"
3. Procedural: "How do I do this?"
4. Interpretive: "Why did this happen?"
5. Navigational: "Where am I?"
The fourth type of help is the one least provided. (Try figuring out a Microsoft error message) and one that is very important.
It's important for new users that they feel safe. They don't trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general (witness the popularity of the "...for Dummies" series of tutorial books.) In many cases these fears are groundless, but they need to be addressed. Novice users need to be assured that they will be protected from their own lack of skill. A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. But this is not a reason for constant "Are you sure?" dialogs, but rather for giving the player a chance to back up and redo an order rather than committing to it. Even Amazon's one click interface allows a user to cancel part of all of an ordering session - as long as the books haven't left the warehouse.
At the same time, an expert user must be able to use the program as a virtuoso. She must not be hampered by guard rails or helmet laws. However, expert users are also smart enough to turn off the safety checks -- if the application allows it. This is why "safety level" is one of the more important application configuration options.
Anyone really interested in user interface design for gaming could do far worse than to read this document a couple of times. I don't always agree with either his analyses or his conclusions, but it definitely makes me think hard and come up with reasons why I think doing something another way is better.
Grim pointed out, in another thread, that sometimes programmers design the game assuming that the players have the same degree and depth of understanding of every aspect of the game as they (the designers) do. And Grim is right. That is a big fail.
There is a tendency among some interface designers to go to the opposite extreme. To design the game to be "user friendly," by constantly pestering the player with requirement that he agrees that he understands the consequences of the order he has given. As one mentor of mine said: can you imagine having a human assistant who constantly said, "Are you sure you want to do this sir?" every time you told him-her to do something? That can get old, quite quickly, even for a noob, and is about as friendly as a straight-jacket.
What designers (and critics of designers) need to understand is that there are a whole bunch of different types of users and the interface has to work for all of them - which sometimes means having more than one interface, not designing for the lowest common denominator. When looking at an interface, it is important to have at least four or five personae and look at the interface from the point of view of each one of them. If Sally Mae Noob can't figure out what to do, it doesn't matter of Harry Curmudgeon likes it or Billy Whizkid finds it perfectly suited to the fact that he has memorized all 372 item codes. The standard questions that must be asked about the personae are:
- What are the gamer's goals?
- What are the gamer's skills and experience?
- What are the gamer's needs?
Speaking of needs, research has shown that when someone approaches any new software, the most important thing to them is not looking stupid. Even if they are alone, that is the fear that a majority of new users experience.
The goal is to provide for the needs of all your potential users, adapting Web technology to their expectations and never requiring readers to conform to an interface that places unnecessary obstacles in their paths.
The user interface for a Web site should follow the general navigation and layout conventions of major Web sites because users will already be used to those conventions. Users spend most of their time on other sites not on the game's, so we should avoid highly unusual interfaces if the idea is to attract and keep a large audience instead of conducting a seminar for 12 interested people on alternative methods of navigating the Web.
A large part of good webdesign is making sure the player knows where he-she is on the website - and therefore knows how to get to everywhere else in the website. Important entry points (the home page, for instance) need to be reachable from everywhere. There should be no need to search for links to those points. Web design should offer constant visual and functional confirmation of the user's whereabouts and options, via graphic design, navigation buttons, or uniformly placed hypertext links.
One way of providing an interface for a skilled and frequent user is to provide keyboard shortcuts. Tapping <alt> <T> rather than having to switch back to the mouse, figuring out where on the page the cursor is and sliding it over to the proper button, menu, or link and then clicking it is a faster and more efficient method of getting to the "Transfer" page. Power users will appreciate it, while newcomers will never even think about it.
The best information designs are never noticed. Two excellent models of interface design are Adobe's and Amazon's websites. Graphic headers act as navigation aids and are consistently applied across every page in the site. Once you know where the standard links are on the page header graphics, the interface becomes almost invisible and navigation is easy.
Help documentation should be always available and specific, at least to the page, if not to the action about to be dealt with. Following a link to a help page should never mean losing any work in progress. There are 5 kinds of help that users want:
1. Goal-oriented: "What kinds of things can I do?"
2. Descriptive: "What is this? What does this do?"
3. Procedural: "How do I do this?"
4. Interpretive: "Why did this happen?"
5. Navigational: "Where am I?"
The fourth type of help is the one least provided. (Try figuring out a Microsoft error message) and one that is very important.
It's important for new users that they feel safe. They don't trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general (witness the popularity of the "...for Dummies" series of tutorial books.) In many cases these fears are groundless, but they need to be addressed. Novice users need to be assured that they will be protected from their own lack of skill. A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. But this is not a reason for constant "Are you sure?" dialogs, but rather for giving the player a chance to back up and redo an order rather than committing to it. Even Amazon's one click interface allows a user to cancel part of all of an ordering session - as long as the books haven't left the warehouse.
At the same time, an expert user must be able to use the program as a virtuoso. She must not be hampered by guard rails or helmet laws. However, expert users are also smart enough to turn off the safety checks -- if the application allows it. This is why "safety level" is one of the more important application configuration options.
Anyone really interested in user interface design for gaming could do far worse than to read this document a couple of times. I don't always agree with either his analyses or his conclusions, but it definitely makes me think hard and come up with reasons why I think doing something another way is better.