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.
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:
0 = I don’t agree that this is a usability problem at all
1 = Cosmetic problem only: need not be fixed unless extra time is available on project
2 = Minor usability problem: fixing this should be given low priority
3 = Major usability problem: important to fix, so should be given high priority
4 = 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.
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
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.
The task was to test our first software prototype without users through heuristic evaluation. After jointly agreeing on a scenario and the tasks to test, each of us did the heuristic evaluation alone, without consulting the other team members! The scenario was simple: just go through the game twice and make notes after each pass.
After every groupmember did this, we sat around a table and had our findings aggregated.
– paper prototype
– user study
– user study
– user study
As you may have noticed, our paper prototype study had not a very fulfilling outcome. Nevertheless we had two minor changes in our paper prototype. The first one is that instead of using a keyboard to type in the name at the high-score page, the application makes a photo of the user. The second one affects the size of the items in the game itself. One user mentioned that they are a bit too small, so we made them bigger ;).
The following pictures show the changes we made in the paper prototype after user testing:
3. The Game (Changes: bigger Items)
4. High-Score (Changes: Photo instead of keyboard)