Since I missed the testing session on Monday - was doing my best to get on top of my exam on Maths on Tuesday - had to arrange my own testing session with friends/family.
I had a total of 6 testers/3 pairs of people.
The two hypothesis that I had were:
2 people or kids will find a way to self-organize to get the correct answers to the questions asked
In pairs people will enjoy playing the game more than if they were to play alone.
Both hypothesis were correct. People did enjoy playing as a team more than playing on their own. From my observations - somebody would take a leading role and say - who has to do what:
"You step on 9, I'll step on 1" and this is how we'll do that
The other person would follow the instructions.
When playing on their own - one of the participants was a 6 y.o. girl - she had no difficulties figuring out how to play the game at all.
Here are the comments from test participants:
100% of participants preferred to play as a team/with a friend more - it was more fun for them.
Test Limitations:
most of test participants were adults, this is a limitation
occasionally some of the buttons wouldn't work - that's technology limitations
I do think that the game is successful, useful and, perhaps, could even be successfully built and released to the general public.
Physical prototype for game MathsFun fully simulates the game. MathsFun is an interactive game that makes it fun for kids to learn basic Maths skills. The concept of the game did not change and is available in this post. To make the game even more fun - I made the game social so that it can be played by 2 kids simultaneously.
Hypothesis 1:
2 people (or kids) playing the game will find a way to self-organize to get the correct answers to the questions asked
Pass/Fail: Most people got their questions right. When they don't get their questions - they are just fooling around intentionally.
Hypothesis 2:
In pairs people will enjoy the game more than if they were to play alone.
Pass/Fail: Will be tested in the form of close-ended question by users doing self-reporting. If users report that they enjoyed the game more when playing together - this would mean that the hypothesis is right. Optionally - I could do 2 rounds of testing - 1. test as 2 people then 2. test with the same testers as 1 person - and then do self-reporting.
When a user types W - in fact - it means 0. Change from numbers to letters is necessary to make the prototype work with Makey-Makey.
Here is the basic input structure to make it work on Makey-Makey:
W -> 0
A - > 1
S -> 2
D -> 3
F -> 4
G -> 5
Up -> 6
Down -> 7
Left -> 8
Right -> 9
Game Logic:
Assume the question is how much is 11 + 4 and the correct answer is 15.
- Wait for 1 user to stand on 1...
- Wait for 2nd user to stand on 5...
If a user stands on 1 - and then on 5 - the answer is correct or stands on 5 - then on 1 - the answer is correct.
If a user stands on a wrong answer - "Zero" the results, say - wrong answer.
Since 2 people cannot stand on 2 numbers simultaneously, during the testing process I will be providing users with instructions.
Materials Used
- cardboard - foil- wires- glue :-) - Makey-Makey
Final Look & Feel
Testing Process
1. Invite 2 participants to test the game.
2. Give background information: the game is for kids to help them learn Maths. When answering questions - one person has to push on one number, another person has to push another number.
3. Ask them to start the game and play 1 round. Observe participants and take notes.
Time to think through the logic of the last prototype for the course in detail, as I have several days to get it done.
So - I'll be testing Social Interactions and assume that 2 people will have fun playing the game and will find their way around as a group.
Hypothesis 1:
2 people (or kids) playing the game will find a way to self-organize to get the correct answers to the questions asked
Pass/Fail: Most people got their questions right. When they didn't get their questions - they were just fooling around intentionally.
Hypothesis 2:
In pairs people will enjoy the game more than if they were to play alone.
Pass/Fail: Will be tested through self-reporting in the form of close-ended question. If users report that they enjoyed the game more when playing together - this would mean that the hypothesis is right. Optionally - I could do 2 rounds of testing - 1. test as 2 people then 2. test with the same testers as 1 person - and then do self-reporting.
Fixes from the last prototype:
- record voiceover under the coat :)
- make numbers bigger in size
Game logic changes:
The main issue is to find an event that would indicate that the answer is correct, since 2 numbers have to be pushed.
How I could do that:
Assume the question is how much is 11 + 4 and the correct answer is 15.
- Wait for 1 person to stand on 1...
- Wait for 2nd person to stand on 5...
If a person stands on 1 - and then on 5 - the answer is correct or stands on 5 - then on 1 - the answer is correct.
If a person stands on a wrong answer - "Zero" it, say - wrong answer.
+ I need to change the questions I ask so that I end up with 2-digit responses.
A problem that 2 people cannot stand on 2 numbers simultaneously. This is a limitation that I cannot find a way around. So, I guess I'll have to explain this to people in the form of instructions.
Time to start thinking about the last prototype.
So, the instructions are as follows:
Final Prototype:
1. Refer or redesign the original prototype
2. Dark horse - do something that seems impossible
3. Add new features: test something not tested yet
Prototyping Process:
- go through evaluation/testing sessions
- take some ideas from it
- SoD (decisions made)
As I brainstormed the different options for the prototype - I decided to stick to Option 3 - adding new features and test something that is not tested yet.
So, what I am planning to do is - make my game MathsFun social, make it work for 2 players. How I think it should work: 2 people could step on different numbers for the solution (for number 10 - one would step on 0 and another one would step on 1).
I'd focus on "social" part of it for testing.
In order to make it work, I'd need:
- change problems that result in solutions with at least 2 numbers (so, from 10 and above)
- the physical component of the game doesn't require much changes, it can stay pretty much the same (but rebuilt again).
Looks buildable and feasible to me :) And also fun when doing the testing :)) I'll need 2 testers at a time.
This week we received quite challenging tasks. At least for music illiterate people, since I don't play any musical instruments :)
So, our first task is:
1. Generate concepts for consistently reproducing and generating 3D movement in space that allows for the musical composition to be accurately played on Theremin.
Theremin operating principles according to Wikipedia are as follows:
The theremin is distinguished among musical instruments in that it is played without physical contact.
The thereminist stands in front of the instrument and moves his or her hands in the proximity of two metal antennas.
The distance from one antenna determines frequency (pitch), and the distance from the other controls amplitude (volume).
Higher notes are played by moving the hand closer to the pitch antenna. Louder notes are played by moving the hand away from the volume antenna.
So, in order to come up with instructions on how to play a certain composition on Theremin - we basically need to translate the regular notes to 3D signs/gestures people would use when playing a composition on Theremin.
Here come the concept ideas:
1. Translate each regular note into gesture language on Theremin and come up with a gesture for each note
2. Translate each regular note into gesture language on Theremin + play with one hand
3. Translate each regular note into gesture language on Theremin + play with 2 hands and a head :)
The second part of a task is to come up with a Pugh Metrix to compare concepts against each other.
So, here are the criteria I believe are essential when it comes to playing musical compositions on Theremin.
1. Learnability
The shorter is the learning curve - the better
2. Fun in the process
The more people have fun when playing the instrument - the better it is.
3. Complexity
How complex the system is - whether a lot of things are required for initial use
4. Number of mistakes people make when playing
The fewer mistakes people make when playing an instrument - the better it is.
We did a testing session this week - it was a lot of fun. I really enjoyed testing my prototype even though it wouldn't always work as intended and sometimes would go crazy :) Mainly because Makey-Makey inputs were sensitive - so when a user stood too long on one input - my ActionScript would count that as a wrong answer.
Overall the feedback was great:
1. It's pretty fun, I like the idea that I need to balance at the same time as completing each math problem. My only issue is that sometimes the problems and answers don't link up e.g. when the sum total is equal to 8, 9 would work.
2. It looks amazing that i cannot wait to play the final concept. only glitch i have so far is the incorrect answers(response?) and also the touch sensibility may need to adjust.
3. It is funny. I believe that it not only bring lots of fun for children, but also can help children do the basic math question. like addition, subtraction. If the circle can flashing, it will be more appealing.
4. It is fun to play for kids as the touch points are decorated in colored and shiny papers. You may want to add a background music behind the game:) overall the game is super great I think!
The prototype was tested by 5 people.
User 1
User 2
User 3
User 4
User 5
Here is the fully completed survey:
Now back to the hypothesis I was intending to test:
#1 Hypothesis to Test:
Kids play at least 3+ game sets (maths questions of 10).
How much time kids spend playing the game is a direct indicator of game quality. If users "stick" to the game and return to play it later - the game is successful and user experience is engaging. Since the prototype is close to the final version of the game - this is the crucial hypothesis to be tested that makes or breaks the game.
I'd say that the hypothesis is validated, user were willing to play longer and they did enjoy the game.
#2 Observations:
This time I'll be observing users to test: size of numbers, size of circles, quality of voice over to notice any design issues that need fixing. Since the prototype is "high fidelity" - it's not the time to pay attention to design details. To collect this data - I'll be using Google Survey with open questions and just regular observations and making notes.
As a result of observing users test the game and their feedback, here is a list of changes that can be made to improve game experience:
add music to the background
make numbers bigger in size
randomize numbers
think and come up with a solution: how to make touchpoints less responsive (I mean so that if a user stands on the same button for a bit longer - ActionScript doesn't accept it as a wrong answer - and therefore the voiceover doesn't get confusing)
Other ideas to be considered:
make the game social - and test it on several users - so that people self-organize to get answers right
come up with a logic that adjusts fast to current user complexity level
Physical prototype for game MathsFun fully simulates the game. MathsFun is an interactive game that makes it fun for kids to learn basic Maths skills. The concept of the game did not change and is available in this post. To make the prototype interactive and fun to use in the physical world - voiceover was added. Thus, the physical input prototype provides a complete sensory experience for users in real life context.
#1 Hypothesis to Test:
Kids play at least 3+ game sets (maths questions of 10).
How much time kids spend playing the game is a direct indicator of game quality. If users "stick" to the game and return to play it later - the game is successful and user experience is engaging. Since the prototype is close to the final version of the game - this is the crucial hypothesis to be tested that makes or breaks the game.
#2 Observations:
This time I'll be observing users to test: size of numbers, size of circles, quality of voice over to notice any design issues that need fixing. Since the prototype is "high fidelity" - it's not the time to pay attention to design details. To collect this data - I'll be using Google Survey with open questions and just regular observations and making notes.
While coming up with the most effective solution for connecting numbers with Makey-Makey - I did 2 additional prototype versions.
Sensor Button
Membrane Button
I decided to stick to a version of Membrane button - since testing prototype barefooted would be ineffective.
Materials Used
- cardboard - foil- wires- glue :-) - Makey-Makey
Final Look & Feel
Testing Process
1. Invite participants to test the game.
2. Give background information: the game is for kids to help them learn Maths. 3. Ask them to start the game and play 1 round. Observe participants and take notes. 4. Ask if they would like to play more. 5. If yes - see point 3. 6. If no - ask to fill out a survey on Google Docs.
.gif){kind=link}