Usability Methods in the Development of Videogames
By: Maral Haar
- 1 What is Usability about?
Generally the user of any interactive products like office applications, household
devices or industrial machines has certain tasks to fulfil. Generally the goals of
Usability are accessibility, utility, ease of use and fun of use. Usability methods are
applied to design an interface which makes the task as easy as possible, as quick as
possible and as intuitive as possible. In the last years, a further goal has established,
namely “fun of use”. That means, to increase work satisfaction and motivation, the
user should have fun while using the devices and tools to fulfil his daily tasks.
With video games the situation is a bit different: The only purpose of all the tasks
offered by the game is to have fun. So the basic requirements like “easy to use and
easy to learn” are just the beginning and the higher goal “fun of use” is critical for
the success of a product. If a player has to think about which button to press, where
to find a command or how to initiate certain actions within the game, he hardly has
any fun, no matter how much fun the general idea of the game is.
That means, usability in games deals with two major issues: Interface design to offer
the player an intuitive and easy way to control the game and game design to make
sure the balance between the players ability and the challenge of the game enables
the flow experience (Csikszentmihalyi, 1975) which is elemental for fun in games.
Additionally it is possible to use usability evaluation methods for requirement analysis
for a new game.
- 2 Why separate from QA testing?
There are major differences between traditional QA testing and usability evaluation.
In QA testing, mostly professional testers play the more or less completed version of
a final product. Major goals here are finding bugs and testing the level design.
Especially to find bugs, the testers don’t play like normal players, but do whatever
odd things come to their minds to provoke crashes or other problems. Professional
testers generally are not representative for the target audience who later on shall
buy and play the game. They often know the product from the beginning of
development and have a similar perspective on it like the developers themselves.
Both because of their profession and because of their familiarity with the game they
won’t see and understand the problems a normal player might have with the
interface. Therefore it is necessary to invite samples of the target audience
(according to age, gender, play-experience and affinity for genres) to evaluate the
interface as soon as possible. And if possible is that you begin even before there is a
running prototype. Usability tests can be conducted with paper mock-ups, flashdemos
or interactive slide shows.
- 3 How to do usability testing?
In every state of development, there are typical questions to be answered and
typical methods to be used. For example, in the beginning it is important
to getfeedback to the idea of the game, to the artwork and the story (if it has one). Here,
interview methods are recommended, where participants get a stimulating
presentation of the designers’ ideas and then can talk about the strengths and
weaknesses in an open interview or discussion. It is also possible in this state to
evaluate existing products to understand requirements for genres, target groups, or
interfaces. Later in the development process, the focus will change to controls, leveldesign
and other subjects.
Generally usability testing is based on small samples and regular tests. Several
studies showed, that samples of 7 persons showed about 95% of all interface
problems which could be revealed with large samples of 30 and more (Nielson,
1994). The tests should be centre of an iterative design
To evaluate an interface, typically use cases are created. For games that means to
think of certain in-game situations and tasks the player may want to fulfil. Such as
situation may be “the player reaches the house and wants to explore it”. One of
several tasks for this situation might be “Open a locked door”. Then those tasks are
divided into single actions like “choose tool”, “choose target” and “use tool on
Those tasks and the according sequences of actions are written down and given to
participants. They shall try to fulfil the tasks without any further help. They just get
the feedback they would get in the final version of the game although without the
final design. For example in a paper mock-up pop-ups are represented with post-its,
in simple flash- or other prototypes there can be just boxes describing what would be
seen there and similar replacements. All actions of the participants should be
recorded and analyzed.
It is also possible to combine these tasks with an interview, where the interviewer
asks what a participant expected when he did an action which was wrong, or the
interviewer may scribble a new interface together with the participant. Another
possibility is an analysis in two steps: After a first glance on the records and notes
from during the test, key sequences of the record are presented to the participant
and then he is asked to explain in detail, what he did, why he did that, what he
expected and so on.
- 4 How to get started (Key dos and don’ts)
Generally all tests should be conducted by persons which are not part of the
development team in any way. Many studies showed that the expectations of a test
conductor influence the outcome significantly, even if he tries hard to avoid that.
Humans are so well trained in reading small non-verbal signals, that they will
understand the expectations. Additionally it is always easier to criticise something in
front of a neutral person than in front of the creator. Nevertheless it is valuable for
the developers at least to see parts of the original tests, especially interviews and
visible actions of participants. Highlight videos are very useful for that purpose.
A very simple way of testing is, to let participants play a game, give them headsets
and record what they see on the screen with their voices from the headset. An
interviewer shall sit beside the player and encourage him to think aloud, which is a
qualitative usability method. Afterwards it can be analyzed in which parts the
expectations of the developers of what a player should think and feel in a certain
situation are fulfilled or not. It might be absolutely OK if a player doesn’t know how
to go on, if there is a riddle and it should be a bit hard to find out how to go on. But
if a player in a tutorial level simply doesn’t understand what his current tasks are,
this should be considered as a problem.
Other methods to get started are task based interface evaluations either of existing
games or of prototypes and mock-ups. In any case the outcome of a test is clearer if
the context is as simple as possible. For example if you have a complete game and
find that the players have problems in understanding the interface you don’t know if
it is only the graphic design like icons, colours and dimensions, or if there is a
problem with the structure like which commands in which menu, placing of buttons
and information etc. Therefore it is better first to test the structure without much
graphic. As soon as most of the participants understand the interface and find it easy
and intuitive (remember to always invite new participants who don’t know earlier
versions!), start with the graphic design.
... to read more articles, visit http://sqa.fyicenter.com/art/