Heuristic Evaluation

This week we did a heuristic evaluation of our prototype and idea. For more information see the articles in [heuristic evaluation]. Some of the heuristics cannot be applied to our game concept, because it is very minimalist in most cases.

Additional Heuristics

We thought of two more heuristics that are more specific to our game, but still general.

11. Easy access to main function

Description:
Obligatory dialogs should be avoided in favor of a straight access to the main function. Use default values instead of blank values.

Motivation:
We have seen a lot of games and applications where it was necessary to set some options before playing. Most could have been set to a default value without bothering the user. The main function should not be hidden behind unnecessary dialogs or settings.

12. Input system is optimal for application

Description:

Input system should be chosen in comparison to all other possible and feasible input solutions as the best.

Motivation:

From our own experiences and the observation of others playing fun racing games on a game console we realized that a lot of people play these games with their whole body. Means when driving to the left they often lean their upper body to the left. So we think that using this subliminal reaction as the primary input control could lead to a deeper gaming experience than using a gamepad. So a Kinect camera is the best choice for our game concept.

Found problems

The analysis with the heuristic error prevention has led to a problem. The description of the heuristic is the following:

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Problem description:
A user may not want to play the game, but only watch the bots race against each other. This can be a problem, because a game has begun and the user is automatically a player even if he does not want to play. We trigger a game when a user is detected. Our philosophy is that this player should be animated to play by watching the bots, but is still free to leave. The game will then reset to idle. There are no other tricky conditions.

Fix:
A possible fix would be to see if the player moves a certain threshold and replace him with a bot if he doesn't.

Severity:
According to [severity] we would rate this as "1 = Cosmetic problem only: need not be fixed unless extra time is available on project". Since this problem conflicts with our philosophy of a fun game. We think it is not fun to watch bots ski.

Verdict:
No change for now.

Heuristic Considerations

1. Visibility of system status

"The system should always keep users informed about what is going on, through appropriate feedback within reasonable time."

Our statement: We will probably have only three system states: idle, game, ranking. The player will know in which quadrant of the screen he or she is based on the head drawn to a corner of it. The screens of bot players will be coloured differently than the players screen. The position in the race will probably be shown as a number under the head shot.

2. Match between system and the real world

"The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order."

Our statement: The concept has changed a bit, but we have begun to match the players movements to the little guys (avatar) movements by deforming them. A player also should see in which screen he or she is.

3. User control and freedom

"Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo."

Our statement: A player will be free to come before the game has started and free to go during the race. By leaving a bot will take the player's place. The lack of many states prevents the user to chose some unwanted option, because there aren't any.

4. Consistency and standards

"Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions."

Our statement: We try to make this game without words or at least not many words. There won't be phrases with the same meaning. The throw action can have two outcomes depending on a collected item.

5. Error prevention

"Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action."

Our statement: A user may not want to play the game, but watch the bots race against each other. This can be a problem, because a game has begun and the user is automatically a player even if he does not want to play. Our philosophy is that this player should be animated to play through the bots, but is still free to leave. The game will then reset to idle. There are no other tricky conditions.

6. Recognition rather than recall

"Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate."

Our statement: There will be no instructions on how to ski down hill, because most people know what good movements are. The users should be able to instinctively play the game. Players can look at bots on how to throw snowballs.

7. Flexibility and efficiency of use

"Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions."

Our statement: Everyone is treated equally. Players who played already will know from the start that you can throw snowballs. All other players will catch on. Actions are so simple they cannot be tailored.

8. Aesthetic and minimalist design

"Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility."

Our statement: It is. Game works because the needed information is already in the head of the player or can be learned extremely fast by looking at other players. In a previous iteration we dropped the idea of drawing the skeleton of a user onto the screen, because it is not aesthetic or minimalist.

9. Help users recognize, diagnose, and recover from errors

"Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution."

Our statement: Our whole game concept is based on the idea that you don't need any help or explanation. Also, this software will be error free! The only possible error scenario is when a user is not correctly identified. He will notice it by not seeing his head shot on the screen.

10. Help and documentation

"Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large."

Our statement: Our whole game concept is based on the idea that you don't need any help or explanation. A help text would introduce additional states that we don't want. It is expected of a player to get the skiing scenario.