Testing the current game – Our plan is to test the game interface indoors without the physical element. Users will be asked to create a Pulse game, define the settings of the game, and play. They will not be told by the testers what the objective of the game is, or how to play it. We believe that a good game interface would help the player learn the rules and objectives, even if they are not experienced. There is a help screen in the application that the users can pop up, which explains the objective of the game and icons. Ultimately, the user test would include testing the interaction between the physical and digital aspects of the game. However, the current stage of the game requires us to test the layout of the game setup and the ability of icons and symbols to communicate. So, we informed users that the icons would eventually be controlled by GPS signal, however that in the test they should point the icons toward their destinations.
Questions we want to answer:
How does a first-time user understand the game rules and mechanics?
How intuitive is it to create the game with Pulse?
Is the game fun to play on screen?
Our setup was to provide a single player with an iPod Touch what was installed with Pulse.
Then, we read them our written instructions (printed on questionnaire).
revisions and changes:
Changes implemented:
-re-ordering the setup menu so to pipeline-it and add default values. This change dramatically reduces the time it takes to create a game. -moving the help screen to appear earlier in the game setup stages
This revision helped the novice player understand the game before entering play.
The game satisfied Nielson’s third heuristic(User Control and Freedome) with the help screen.
-Eliminate waiting screen’s spinning clock when done waiting
-make “my gps icon” prominent
-label health elements
-show feedback when my player has attacked opposing team member.
Test users mentioned that they needed to know if their attacks were received.
Initially this feedback was missing from our interface. Post testing, we are in the process of implementing the feedback feature where a player can see the damage on the opponent. This change would satisfy Nielson’s first heuristic(visibility of feedback), as well as narrow the Gulf of Evaluation.
design reflections: The users are more eager to engage with the functional prototype than they were for the paper prototype. Our guess it that the application seems “real”, and they experience fewer obstacles in navigating the menu items. The paper protoype was not part a a bigger system (mobile OS). Therefore, some dead-end or similar problems were “solved” by re-starting the test. Having a functional prototype empowers the user to find a way out of our design flaws, giving us a better sense of their impact. Time was unmeasurable with the paper prototype, since what it took us to manipulate the prototype was significant and not regular. The functional prototype allows us to measure time in a more precise way, and time proved to be a very rich source of information. In our experiences as test users of other team’s interfaces, there was a sense of awe that came in reaction to knowing that the students made things work. And feeling this motivated us to try out the apps.