the second track for MoveTheBeat

major issues that were discovered and severity + possible solutions

Here are some issues we discovered during the test. Not all of them are mentioned, just the major ones (for the sererity ratings we used Jakob Nielsen’s serverity ratings for usability problems):

– Game does not restart properly after saving the high-score (severity: 5)

possible solution: some variables might not be reinitialized properly

– electro-track is to hard to play. Even for users with a common knowledge of music (serverity: 3)

possible solution: make an other song that is slower and easier to play

– Specialsound-button is a bit hard to reach (serverity: 2)

possible solution: rearrange buttons according to fitt’s Law

basic information about the users that have been tested

User 1:

age: 26

profession: computer scientist

gender: male

hobbies: computer, guitar, soccer


User 2:

age: 23

profession: gender studies

gender: female

hobbies: shopping, painting, meeting friends


testing of the application with the Think Aloud method

Today we are testing our application with the Think Aloud method. We prepared some tasks the user had to perform during the trials. The user also had to verbalize his thoughts while interacting with MoveTheBeat.

Here are the tasks/Questions the user had to fullfil:

Spiele das Spiel MoveTheBeat zwei mal. Wähle den Electro-track für das erste und den HipHop-track für das zweite Spiel. Mache jeweils am ende des Spiels ein Bild für den High-Score von dir. Versuche während des Versuchs zu beschreiben was du gerade tust und was du vorhast. Auch Probleme mit der Applikation können laut ausgesprochen werden. Erwarte nicht von uns dir dabei zu helfen. Es geht darum selbst heraus zu finden wie die Anwendung funktioniert.

Test setup:

Time – 15:00

Place – Alex‘ kitchen

recording technique – Iphone, paper and pencil, brain


Here are some pictures of our test setup:


Photo 30.01.13 14 14 44 Photo 30.01.13 14 14 52


That’s us working on MoveTheBeat

Photo 29.01.13 17 39 50

the software prototype based on your paper prototype

1 3 4 5

description of the resulting changes to our prototype

As you may can guess, we fixed the problems we found in our heuristic evaluation. The first one was important but simple. We just had to implement a high score display into the actual game. For second problem we found we used the same „load function“ as in the other menues of our application. The user has to put his hands over the „photobutton“ as it changes the color. After about three seconds a photo will be made. This prevents the user from accidantally taking a photo.


Even though we just found two problems with our heuristic evaluation we are still glad that we have done it because, as you can also see in the ratings, the problems we found were very serrios.


description of the resulting changes to our prototype

As you may can guess… we fixed the problems we found in our heuristic evaluation. The first one was important but simple to implement. We just had to put the high score into the game.

For the second one we used the same „load function“ as in the other menues. If the user wants to make a photo he/she has to hold his/her hand over the button as it changes its color. After about 3 seconds a photo of the user will be made.

Even though we didn’t found a lot of problems, the ones we found were very important. It is always usefull to do a heuristic evaluation.


The problems you found + severity rating of these problems

In our heuristic evaluation we found two problems, after a long discussion. The first one is located in „the visibility of the system status“. There is no High-Score display during the game. Even though we had it in our Storyboard we just forgot it. Furtunately we made a heuristic evaluation ;).

The second one is a problem  of „Recognition rather than recall“ and of „Flexibility and efficiency of use“. The issue is about the photo the user makes for the high score at the end of the game. Sometimes the user accidently triggers the „photobutton“ because his/her hand graces over it.


For the rating of these problems we used Jakob Nielsen’s rating scale to rate the severity:

= I don’t agree that this is a usability problem at all
= Cosmetic problem only: need not be fixed unless extra time is available on project
= Minor usability problem: fixing this should be given low priority
= Major usability problem: important to fix, so should be given high priority
= Usability catastrophe: imperative to fix this before product can be released


Since we all did the heuristic evaluation we decided to take the highest rating into account. For the first problem the ratings were




So we fixed it immediately!

For the second problem the ratings were




so we gave it a high priority.




set of two project specific heuristics

We used Nielsen’s updated list of Ten Usability Heuristics as our basic set of heuristics.

• Visibility of system status

• Match between system and the real world

• User control and freedom

• Consistency and standards

• Error prevention

• Recognition rather than recall

• Flexibility and efficiency of use

• Aesthetic and minimalist design

• Help users recognize, diagnose, and recover from errors

• Help and documentation


In addition, after a long discussion, we found two more project specific heuristics.

The first one is

• accuracy

That is because in our application it is very important that the sound-sample comes directly with the triggering of the respective Icon/button, so that the user gets points and plays on the beat.

The second on is

• arrest attention

MoveTheBeat is made for public places. The user and his frinds should come closer when they see/hear it. When somebody plays the game other people should stop and be amazed.