|
[Torque's Eric Preisz and two Full Sail usability center PhDs offer four techniques to help make your game more accessible -- even if you don't have access to a giant lab and dozens of focus testers for feedback.]
Usability is a crucial factor when attempting to reach large, diverse audiences with a game. A commonly stated rule-of-thumb is that if your player doesn't understand the basics of your interface in two minutes, they'll stop playing your game. Therefore, good usability is critical to game success.
When it comes to designing usable games, it is critical not only to understand how your target audience experiences your game, but also how other groups of individuals not in your target audience will react to a product (professionals call these "core" and "fringe" users).
For financial and quality reasons, increasingly usability work on games is being done by specialized user experience centers with broad access to large diverse groups of potential users and whose team members have extensive training and experience in usability assessment methods.
This is a rare combination of factors, however, and means that such user experience centers are typically located in and around universities, and at the few large game companies that can afford an in-house usability center.
Although this makes it harder for many game studios to get access to these groups, user research teams can pay for themselves quickly in several ways including: keeping a development team working together for a common achievable and prioritized set of goals, alleviating investor concerns about customer targeting and focus, improving the efficiency and effectiveness of development tools, and most importantly, improving user experience within a game environment.
An early focus on usability on game projects is financially critical -- research shows that the top four reasons for development going over budget are all related to unforeseen usability problems and 80 percent of the cost of patching and maintenance on software products is due to unmet or unforeseen user interface needs.
Unfortunately, cost, location, and personnel availability often make it difficult for small to midsize studios to set up or even get access to user experience centers. While not every game company can afford the services of a professional user research team, every game can benefit from the basic techniques these groups use. Many of these techniques are simple and cheap enough to be implemented by developers and artists directly.
In this article, we'll introduce four usability ideas, a simple methodology, and discuss pros and cons for each. These concepts and methods can be understood and implemented without specialized knowledge, and can pay dividends both during development and after a game ships.

Think-Aloud Technique
Methodology. In the think aloud technique, the gamer sits down to play the video game while a user experience team member is seated nearby to listen and take notes. The user is given specific instructions that as they play the game, they are to say out loud the reason they took each action. This allows the team member to document both their actions, and what the user was thinking as they took them. The team repeats this with multiple gamers to get multiple perspectives and viewpoints.
Example. During a recent test, a player chose to try to load a gun with a water bottle by dragging and dropping the icon for the water bottle (a blue-gray tube with a narrow end) onto the icon for the weapon, saying "this looks like a bullet, so it's probably ammo for the gun." Their actions, and their spoken-aloud explanation, made it clear that the icon for the water bottle was confusing and needed to be redesigned.
Positive aspects of the Think-Aloud Technique
- Team members are able to understand what a player is thinking. This allows them to find and document areas of the game that caused problems, often with multiple players.
- This technique works well in an iterative design and testing process. Research has shown that 75 percent of interface design problems can be discovered using a handful of participants (around five). With an outcome that fast, results can be generated in a single day and passed on to the development team for fixes.
- Other team members (like developers, artists, and producers) can watch and immediately see firsthand when there are problems with the game. This saves time and helps them to understand why the fixes are important. Allowing developers to see a product in action with players is extremely powerful when the player makes a mistake or takes an action that developers never took into account.
Problems with the Think-Aloud Technique
- Many players have no problem talking while they play, but some will have problems with this. Uncooperative players (intentional or not) can cause frustration and lost time.
- "Thinking aloud" doesn't come naturally to players. In a natural setting, gamers rarely verbalize all of things they are doing in a game. It's also possible that in trying to explain what they're doing, they may make up reasons that are different from the actual cause of a behavior.
- If it's hard for some people to walk and chew gum at the same time, you can imagine that it's hard for many people to play a game well and talk about it at the same time. Often they focus on one or the other, with less than ideal results. You can try to fix this by asking them what they're doing or thinking if they stop talking at some point.
|
Allowing players to fail is the most important part of it in terms of improving the game.
In fact the ideal customer is stupid and rich.
Sure some of them are smarter than the average bear but if you want money you need to appeal to rich dum dums.
I hear apple has the best supply of such folk.
With that in mind cant a developer just hang around outside the nearest apple store to recruit the best possible subjects?
Hell you only need one, just watching them flail around confused for a few minutes is always invaluable feedback.
I don't know if that makes you a better or worst specimen, but I guess that polarizing it in such a manner would just diminish your fantastic talent for dumb insults. I respect you for that.
Check out our blog on gaming: http://answerlab.com/blog/2010/04/27/gaming-grows-up/
This is a good set of procedures. I can't help but wonder if they're so simple why so many top-quality game designers don't practice them? Sitting in a group of people playing the same game it QUICKLY becomes obvious which features were not properly quality tested. Important features like the reticle on an FPS game being too transparent, or the wrong color - or strange delays before or after jumping or colliding that make continuity a struggle.
They can also ask each other questions when in doubt ("I wonder wonder how this item can be used?"). This helps in a natural way to put words on things that are confusing. This doesn't work as well in the single gamer variant, because the observer is normally not allowed to help figure things out (that would defeat the point), and asking questions can be awkward and unnatural when not as part of a two-way conversation. Having two people be in it together helps fostering a natural ping-pong of verbalized ideas between them, which is exactly what is needed.
1) If one person has a very dominant personality, the other is more likely to agree with the first person's opinions rather than stating his or her own;
2) If the point of usability testing is to find the problem areas for your game (frustrating controls, excessively difficult puzzles, etc), then having an extra person to assist in figuring out these issues can hide them from you- the developer needs to see where and how people are getting frustrated. I'm not saying testing two people shouldn't be done- I'm warning that it shouldn't be done exclusively.
Also, when I test people one at a time, I create a dialogue- it's hard to explain in this amount of space, but it is very possible to create an environment where the think aloud process feels like a conversation with the researcher.
1) I'd like to comment on the 3rd problem with heuristic evaluation. This was an issue I was struggling with while working with an indie developer. To solve the problems of subjectivity and the lack of quantifiable ratings I developed (and published) a heuristic evaluation technique that assigns a weighted severity rating to problems based on the frequency that similar problems were observed by video game reviewers. You can find (and download) the paper here: http://hci.usask.ca/publications/view.php?id=184
2) I think usability evaluation is actually very accessible to indie developers, and a really good avenue that should be explored. Some of these techniques are very cost effective, and provide great focused feedback for indie developers.
3) While Federoff's work is very interesting, it is a bit outdated now. Anyone interested in heuristic evaluation in video games should look up the works of, D. Pinelle, H. Korhonen, H. Desurvire, and C. Koeffel.