Category: F2025 – Aya

User testing played an important role in identifying both design and technical issues. I began by testing the project myself. Originally, the controller was designed as a steering wheel, but I quickly realised that due to the limited space between the wheel and the box, the movement felt restricted. Replacing the wheel with a flat record-disc style controller made the rotation smoother and more comfortable. This change improved the overall usability before involving any external testers.

For the first round of user testing, the participant was able to understand the gameplay immediately and interact with the disc without any issues. This confirmed that the core interaction was clear and functional.

user 1

The second user test, however, revealed a major issue. At one point in the game, the disc stopped turning, and the player became frustrated since they were aiming for a high score. I later realised that this was due to the physical limitation of the potentiometer, which cannot rotate infinitely. Because there was no visual cue indicating the rotation limit, the user assumed the controller had broken. This highlighted the need to add a clear indicator to show when the disc has reached its endpoint and that the user needs to rotate in the opposite direction.

user2

By the third user test, I explained this limitation to the participant beforehand, and the interaction went smoothly. They played without problems and suggested adding a character, such as a doll or a real figure on the screen, to make the visuals more engaging.

user3

Overall, the user testing process helped refine both the physical design of the controller and the communication within the game interface. The feedback guided improvements that made the interaction more intuitive and reliable.

User Testing Video

For user testing, I told my test user to start the game without giving any instructions. The user immediately figured out that the controller was not an ordinary one because it’s just a piece of plastic with nothing on the outside. Luckily the first thing he tried was to tilt the controller, which made the character move, allowing him to complete the first level of the game.

One aspect of the experience that worked surprisingly well was that all my test users somehow knew that that the goal was to move upwards even though I didn’t indicate that the finish line was there. It then became clear that because the bottom boundary of the maze is showing, the users assumed that the finish line was in the other direction.

The biggest area that can and will be improved is the robustness of the controller. It’s currently an accelerometer and vibration motor taped to the controller case, which makes it weak and sometimes makes it fall apart. I plan to use the glue gun to fix this. Another issue is the amount of wires going out of the controller. There are currently 5 wires for the accelerometer and 3 for the vibration motor. While these are essential to make the game work, I can make them less annoying by using tie cables to clamp them all into one single wire.

I didn’t need to explain anything to my test users, however, the game might not be as intuitive for other users. I plan on adding an instruction page in the beginning and some text under the controllers on the box that tells users they’re supposed to tilt them to move.

 

User Testing Video With only P5 (using keyboard instead of arduino):

IMG_7745

User Testing Video of One Push Button:

IMG_7748

User Testing Video of Progress with more buttons and design:

IMG_7754

For my user testing session, I asked my friend to try out my project without giving her any instructions. I wanted to see if she could figure everything out on her own just from the way the interface and the game are designed. The first thing I noticed was that she read the instructions on the page and understood the goal immediately, which was honestly a relief. She didn’t ask any questions, so the basic mapping between the buttons and the falling emojis made sense to her. That part of the experience seems to be working exactly how I intended.

Once she started playing, her feedback was really helpful. She enjoyed the game a lot, in fact, she kept wanting to play even after I stopped recording, and she tried beating her own high score multiple times. That told me that the core idea is fun and engaging. But she also pointed out a few things that I definitely need to improve. The main issue she mentioned was responsiveness. Sometimes the game feels a little slow to respond even when she hits the button at the right moment. When multiple emojis fall quickly, pressing two buttons in a short time makes the game slightly laggy. This helped me realize that the input handling needs to be optimized so that the game processes button presses more instantly, especially when things get fast.

She also said that adding sound effects for correct hits would make the experience more satisfying, which I completely agree with. That’s something I want to implement next. Another important improvement is creating a proper end screen with the final score and a high score tracker, because right now the game just keeps going without a clear ending moment. An end page would make the game feel more complete and polished.

On the physical side of the project, I had a few challenges. I wasn’t on campus for most of the week, so I only had Wednesday to work on the hardware. I tried soldering the buttons onto the board, but when I tested them, the connections kept failing. Because of that, I had to temporarily tape them with conductive tape just to get the buttons working for testing. This also means the buttons aren’t fully placed into the holes yet, and 2 leds weren’t working at all, so I had to test it without them.  Once I solder everything properly, the inside of the box will look much neater, and the wires will be able to pass through from underneath the LED buttons. After that, I’m planning to close the back of the box, but I’ll leave a small opening so I can still access the components whenever I need to fix or update something.

Overall, this user testing session helped me see what’s working and what still needs attention. The concept, gameplay, and instructions are all clear, and the interaction makes sense even without any explanation. But I also realized that I still have a lot to improve in terms of responsiveness, speed, physical build quality, and overall design. The good thing is that my friend actually enjoyed playing, which reassures me that I’m on the right track, the project just needs more refinement to reach its full potential.

User Testing

For user testing, I let my sister test out my project. For this test, I didn’t give her many instructions beforehand, so I could observe how intuitive the system is.

User Testing Video:

 

Observations

My sister was confused at first because the mapping between the physical buttons and the actions on the screen wasn’t obvious.

I had to explain the concept of the project and how the buttons work, which shows I still need to make the controls more self-explanatory. Once explained, she understood the idea of selecting a year and choosing between music or news.

My sister suggested adding a sound effect when the selected decade changes so that the user is aware, she also suggested increasing the value range between the time periods because she felt that they were too close to each other (as seen in the video, she overturned the potentiometer and reached the last time period when she meant to only go to the second one).

She also criticized the play button (plays the music/news) and said that I didn’t really need it since the potentiometer changes the sounds anyway, so it would be redundant. Instead, she suggested having an activation button that “activates” the machine after the start screen.

Overall, it was clear where the experience worked and where it could be improved.

What’s Working Well

• The music playback is smooth now, with no lag (that was a big issue until an hour ago).
• The LEDs on the breadboard respond nicely to the potentiometer.

Areas to Improve

• The “news” button currently requires a long press. I plan to fix this so that a single press triggers the news playback.
• I want to add a clear response from P5, for example: the LED on the sketch lights up along with the LED on the board.
• I also need to display the selected year on the P5 screen so that my sister could see what they’ve chosen without instructions.
• The buttons need labels (“music” and “news”) so users immediately understand their function.

What Needed Explanation

The most confusing part for her was how the selection process works:

• How the potentiometer selects the year
• How the buttons choose music or news

To make this more intuitive, I plan to:

• Clearly display the current year on the P5 sketch
• Label the buttons on the breadboard
• Possibly add visual feedback cues (lights, animations) so users know their input is registered

Next Steps

• Improve the user interface on P5 to show selections clearly
• Fix the news button to work with a single press
• Add more intuitive labeling and feedback on the hardware
• Look for more audio files to make the selection more vast

User testing was extremely helpful: it showed me what’s intuitive, what needs clarification, and how the experience can be improved for someone using it for the first time.

User Testing Video:

IMG_1108

1. Have people try your project without giving them any prompts/instructions and see how they use it.

I let my friend step onto the dance pad and try Foot Loose completely blind. No instructions, no hint about the pads, nothing. I just pressed Start and watched. Right away, she understood the basic idea: arrows fall down their lanes, you step on a matching pad. She wasn’t lost or confused about the “goal” of the game, which was a huge win.

But the moment she tried to play seriously, the weaknesses started showing. She hesitated, second-guessed pads, and kept glancing down because she wasn’t fully sure what counted as a “hit.” The center pad especially caused chaos; it triggered randomly and confused her more than it helped.

2. Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and the experience?

What she figured out:

• Arrows = instructions.
• Colors = lanes.
• Pads = controls.

Where she got confused (and why):

• Instructions were too vague.
  She didn’t know exactly when to step. She asked me later:
  “Do I hit when it touches the line? Or when it’s between the two lines? Or when it’s dead center?”
  That hesitation slowed her down.
• The center pad was unclear.
  It kept triggering even when she didn’t mean to step on it, and she didn’t know what it was for. The “●” symbol made sense in theory, but in practice it caused more accidental hits than intentional ones.
• The game felt too fast.
  She understood the mapping, but the speed didn’t give her time to react. On easy mode, she still felt rushed.

So yes, she understood the mapping, but the timing window + speed made the experience harder to grasp on her first try.

3. What parts of the experience are working well?

• The directional pads (L, D, U, R) worked great.
  They triggered reliably and matched the arrows perfectly.
• Visual clarity:
  The colored lanes + falling arrows made sense instantly. She said, “Oh, okay, I step where it matches.”
• The core mechanic:
  Hit arrow → get GOOD / MISS → see score go up.
  She understood the flow without me narrating anything.
• Pacing of feedback:
  The “GOOD” and “MISS” flashes were readable and rewarding.

In short, the skeleton of the game works extremely well. The player can understand the entire concept just by watching it for 5 seconds.

4. What areas could be improved?

• Instruction clarity:
  I need to explicitly say:
  “Step when the arrow is inside the dashed zone.”
• Remove the center pad from gameplay.
  It’s physically useful as a standing spot, but as a sensor it creates noise, misfires, and confusion. It’s not worth the chaos.
• Slow the game down on Easy mode.
  Beginners need space to understand the rhythm before it speeds up.
• Broaden the hit zone.
  The current timing window is too strict. Expanding the dashed lines will make the game fairer and easier to enjoy.

All of these changes directly help first-time players “get it” without needing me to explain anything.

5. What parts did you feel the need to explain? How could you make these areas more clear?

What I felt the urge to explain while she played:

• “Step ONLY in the dashed zone.”
• “Ignore the center pad; it’s just a place to stand.”
• “It’s fast, don’t worry, the game is supposed to slow down.”
• “You’ll get a GOOD only if you step in the exact timing window.”

Basically, anywhere I wanted to explain was a UI failure, not a player failure.

How I will make it clearer:

• Rewrite instructions to be exact, not general.
• Remove ●/center input entirely.
• Increase the hit zone size.
• Slow the spawn rate on easy mode.
• Maybe add a small mini-tutorial or animated demo before the game starts (optional).

Final Takeaway

The user testing confirmed that the concept is strong and intuitive, but the details such as timing clarity, center pad behavior, and pacing need refinement. Once those are fixed, the game will be fully understandable on its own, which is the whole point of this assignment.

Link to Video

Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

I had two users test my final project, “Tokyo Flight,” and they were able to figure out how to play the game using the physical airplane controller I built. The instruction page was helpful overall, but they initially got confused because it first explained how to play the game within p5 only. This made it very confusing for them to understand how to use the physical airplane to control the plane on p5. The tester eventually understood the mapping between the controller and p5. However, the button on the physical airplane took them some time to understand how it works. Thus, I need to improve the instruction page to clearly explain how to play the game using the physical airplane.

What parts of the experience are working well? What areas could be improved?

The airplane on p5 successfully received sensor values from the accelerometer, so the main feature of the game was working perfectly. Specifically, the airplane on p5 moved vertically according to the tilt of the physical airplane. However, one of the LED pins was not working properly due to a loose wire connection. I had to fix it manually during the game to get the LED to light up. To rectify this issue, I am thinking of using a glue gun or tape to make the connection stronger so the wires do not come loose during the game. Furthermore, the testers told me that the entire experience was a bit too laggy, which made it difficult to play the game. To fix this, I moved all the files to VS Code and used Live Server, which resolved the lagging issue.

What parts of your project did you feel the need to explain? How could you make these areas more clear to someone that is experiencing your project for the first time?

I definitely need to improve the UI of the p5 interface, since some text are overlapping with each other, and the Airplane Collection page has poor UI design. Specifically, the point values are hidden behind each box, so users cannot easily understand how many points they need to get to unlock each skin. I also realized that I needed some kinds of background music to make the atmosphere better, based on the tester’s feedback. I added Ghibli music since the main theme is about this ghibli movie called Wind Rises. The tester also told me that the accelerometer is very sensitive and that depending on the delay, sensor values are sent to p5 too quickly. This causes the tilting movement of the physical airplane and the airplane movement on p5 to be sometimes mismatched. I will experiment more with the delay values on arduino to find the best delay value that avoids lag or mismatch between the real tilting movement and the airplane movement on p5.

User Testing Video

Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

Other than the Arduino port selection part,  she didn’t really get confused. Once that step was done, the controls felt intuitive. Pressing the button to make the character jump is simple and easy to understand, so the connection between the action and the game response is clear. One thing to note is that right now, using a button makes it feel very easy, but once it’s implemented on a glove where the player has to “shoot” like a webshooter, it will be more challenging to coordinate. So while it’s simple now, the final version will require more precise timing and movement.

 

What parts of the experience are working well? What areas could be improved?

The game itself is running smoothly,  jumps feel responsive, movement is predictable, and the player gets instant feedback, which keeps it engaging. It’s easy to pick up and play without much explanation. The main thing that could be improved is the platform spacing and variation. Right now, the platforms are a bit too similar, so the game can feel repetitive. I tried making them more random before, but that sometimes caused impossible jumps. Ideally, I want to add more variety and challenge without breaking the game’s fairness. 

 

What parts of your project did you feel the need to explain? How could you make these areas more clear to someone that is experiencing your project for the first time?

The part that needed the most explanation was still the Arduino port selection. It’s a technical step that interrupts the flow and could confuse someone who hasn’t done it before. I want to find a way to skip it or make it automatic so players can get into the game immediately.

User testing Video
Have people try your project without giving them any
prompts/instructions and see how they use it

https://youtu.be/KjYdtzcL7hw

Sidenote: I advice to lower the volume of the video since there were people being loud nearby

---

• Are they able to figure it out? Where do they get confused and
why?

At first, I forgot to mention in the instructions page what the potentiometer was, which is why the person who tried my game couldn’t figure out what was the tool that controlled the size of the sphere. After this, although it didn’t take her long to understand how the potentiometer worked, she commented that it would be helpful to have a small description of how it is used.

Do they understand the mapping between the controls and
what happens in the experience?

Fortunately, they did understand what the potentiometer was doing to the sphere and expressed her interest in the interaction.

• What parts of the experience are working well? What areas could be improved?

Although so far everything in my sketch and Arduino works as I wanted

• The sphere shrinks and grows in response to the potentiometer
• the songs change in response to the button
• the red LED turns on when the sphere reaches the maximum or minimum size
• the green LED turns on when the sphere reaches a small range (between 290 and 300)
• the “winning” size triggers the end page and then the user can go back to the homepage
• there is a homepage and an introduction page

I feel like I could add a last component to make it more interactive, which would be the spinning of the sphere with another potentiometer. I think I could also make the growth and shrinking of the sphere far more smoother, and maybe add some exciting element for the winning page. While I am aware that on the surface this interactive project seems simple, it has forced me to push myself far outside my comfort zone, and I am happy with my progress so far.

• What parts of your project did you feel the need to explain?

Like I previously mentioned, I realized I failed to explain in the instructions how the potentiometer works and how it can be identified by those who don’t know what it is. I also realized I need to explain what happens when the spheres reaches the incorrect sizes that trigger the red LEDs and what triggers the “win”.

• How could you make these areas more clear to someone that isexperiencing your project for the first time?

I believe it would be best to introduce this information in the instructions page since this is the most efficient way to inform the user while also keeping their focus on the information before splitting their attention to the p5 sketch/screen  and the Arcade/arduino game box.

Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

The one thing I did not make very clear is where they should point the light to, which are the light sensors. I think testing this with people that have done IM classes before was not suitable because they knew how each sesnor looked like therefor knew how to trigger them. So the light sensors and water sensors should be intergrated in a way that allows the user to understand what they should do to trigger the sensor.

• What parts of the experience are working well? What areas could be improved?

I think the overall functionalities of the sensors work well, and the thresholds are defined well. I want to make all the wires connected to the Arduino and bread board sit more neatly because they do get tangled at time. I also want to make sure that the the wooden case around my project has a small hole or opening to let the connection from the laptop to the Arduino.

• What parts of your project did you feel the need to explain? How could you make these areas more clear to someone that is experiencing your project for the first time?

One part of my project that I needed to explain more clearly was how users should interact with the sensors—specifically, where to point the light for the light sensors and how to activate the water sensor. Because many of the people I tested with had prior IM experience, they already recognized what the sensors looked like and intuitively knew how to trigger them, which made it harder for me to notice confusion. For a first-time user, however, the mapping between their actions and the project’s responses is not immediately obvious. In future iterations, I want to better integrate or label the sensors so that users can naturally understand where to shine the light or where to place the water without requiring external explanation.

DEMO of User Testing:

IMG_8795

 

When I gave people a chance to try my game, they were generally able to figure it out easily. From my experience during the midterm project, I learned that providing clear instructions is very important, and I applied that lesson here. At first, players were surprised to see apples used as controllers, but I am happy with this decision because it made the game more engaging and encouraged curiosity. The instructions I provided explaining that the red apple moves the character to the right and the green apple moves the character to the left made it easy for them to understand the mapping between the controls and the game actions.

One small point of confusion was that I wrote “touch the apple,” but in practice, players needed to press or squish the apple for the character to move. This is something I can clarify better in the instructions for future users.The part of the game that worked well was moving the character from one side to another, as it felt natural and responsive. Another improvement suggested during user testing was related to catching items: originally, the character caught food near her legs at the very bottom of the screen, but after the suggestion, I moved the catch area so it aligns better with the character’s position. This made the game feel more intuitive and enjoyable.

The part of the experience that required more explanation was how the apples work as physical controllers. While users understood the concept after reading the instructions, I could improve this by adding a visual cue or short tutorial in the game showing how to press the apples to move the character. Overall, clear instructions, intuitive controls, and small adjustments based on user feedback made the game easy to understand and engaging, but highlighting the physical interaction more clearly could improve the first-time experience.

Please see below the user testing video:

User Testing