Prototype Development

Up to this ‘Computer Prototype’ phase, our team has developed the low-fidelity paper prototype with our initial concept, has performed the usability testing with potential users, and has received valuable feedback for our game. From these design activities, especially from the usability testing, we could make clear on what aspects of our design to be improved and what aspects to be remained as it is. Moreover, since we had two testing sessions with User 1 (1st session with initial prototype and 2nd session with improved paper prototype) and we received highly positive feedbacks from the improved paper prototype, our team decided to mostly sticks to our improved design.

Firstly, our team has agreed with adhering to the initial design of buttons and labels. During the first usability testing session with User 1, we received the feedback that the user had no trouble in positioning required buttons and in understanding the meaning or function of buttons and labels. And, we observed that the user was able to navigate between pages using the buttons and labels easily.

Also, we decided to keep our game level system the same. In ‘Usability Testing’ phase, we suggested to modify the level system such that option of level select is eliminated and the game is always start at the level one to provide less complicated game flow. However, since the User 2 is proved unsuitable for our product and the first user clearly understood how to manipulate the application, our initial design of game level system is decided to remain the same. Also, our initial design provides better environment in choosing the right game for the users.

On the other hand, the biggest change in our design is the image of starting point and ending point. It was initially designed that the users simply place the finger on starting area and follow the path. Now, however, we decided to change this feature to ‘Dog and Bone’ system instead of simple swiping finger on track because, during the testing session with User 2, the user was not motivated and did not understand the goal of the game. How it works is that the user drag the ‘Dog’ image to the ‘Bone’ image. ‘Dog and Bone’ feature is more conspicuous than the ‘Finger Swiping on Track’ in terms of the purpose of task, so we expect that users could figure out little more easily and intuitively their task during the game. Furthermore, ‘Dog and Bone’ system is more purpose-driven than the ‘Finger Swiping on Track’ system, so we also expect that it can more motivate the users.

Next, we implemented the visual feedback on the boundary of the track. From the ‘Low-Fidelity Paper Prototype’, the teaching assistant pointed the absence of visual or audio feedback to alert the penalty on the score. Also, during the usability testing, it was difficult for the users to recognize the penalty on the score when they touch the boundary without the visual feedback. Thus, we implemented the feature that when the users touch the boundary of the track, the color of the track wall is changed into the red to visually warn the users. And as soon as they get back to the track, the color of the track wall is back to its original color.

Lastly, we made some minor changes in the user interface. Firstly, we made the brief instruction page as the very first page. The User 2 had requested to have brief instruction before the main menu so that the users know the game tasks. Also, even though the user manual will be provided, it is considered to be more reasonable to provide explanation and instruction about the game in the application itself. Second change is the addition of the ‘Quit’ label to indicate the location of home button of the tablet device. Since User 1 had no technological background in tablet device, the user could not figure out how to quit from the running application. It was expected that most of potential users would be like User 2 and our team has overlooked this issue. Therefore, we added the ‘Quit’ label in the main menu page.

In this stage, the functions of the buttons that bring the new page to user and some of the game interaction features were critical to implement in this stage. One of the most important aspect of our product is easiness of navigating between pages. Since we only had one suitable user to test on this, we aim to verify the clarity on design and functions of each buttons and labels. Furthermore, during the low-fidelity usability testing, we could not successfully test the actual game interaction feature, such as penalized in score for touching the boundary. Therefore, we plan to test the visual feedback feature of track wall whether it is effective enough to warn the users.

Usability Goals

• Users, whether they have experience in using iOS devices or not, should have no difficulty in navigating between different pages and should be able to reach to the page they want.
• The user should require only minimal aid from the examiner navigating the application but not in completing a game
• Users should understand how the game works and know from observing the score and feedback from the game what factors increase or decrease their performance in the game.
• The game time shouldn’t be too long in duration - it becomes too easy and therefore boring for the user. The game should be challenging for the user.

Types of Users

Ideally, the usability tests should be performed on a post-stroke patient with hand or finger motor impairment. If the examiners are unable to attain such a subject, then a post-stroke patient going through movement rehabilitation or having difficulty with hand-eye coordination would be best. Otherwise, to test the flow of the game, a third party person who has had no interaction with the game should test the intuitivity of the game.

Prototype Handling

Please refer to the User Manual for how to work the device and game.
Since the prototype is still in development phase, there are some missing features. Therefore, one of the team member will sit beside the examiner and apply the ‘Wizard of Oz’ technique corresponding to the examiner’s action on the product.

Interacting with Users

Team will assure the test users that the purpose of the testing is only for evaluation of the product design, not the users. We will try to make the users comfortable without pressure so that they can more focus on the testing. As politely as possible, we will encourage test users to engage in testing and will ask questions to gain the insights from them. Lastly, we will remind them that they are free to stop the testing, if they want to.

Test Equipment

• Apple iPad (running iOS 7+)
• Video recording device
• Test material documents
• Pen

Test Documents

• Introduction
• Consent Form
• User Manual
• Pre-test Form
• Post-test Form
• Test Script

Test Procedure Instruction

1. Briefly introduce the purpose of this usability testing
2. Briefly explain about the product
3. Provide the consent form and pre-test questionnaire documents and ask them to fill the documents
4. User manual provided to the test subject.
5. Either wait for user to conduct a task at will, or pick an example from the test script and fill accordingly.
6. Ask the test subject to start the testing with the computer prototype and examiner start to record the testing
7. During the testing, examiners pay attention to test subject’s behaviors, especially when they navigate between pages and play the game, and make note of them on the test script.
8. After the test, post-questionnaire document is provided and ask them to fill the document or assist them in doing so if necessary.

Reporting Results

The evaluators will be filling out the observations needed for every task the user must complete. There will be a video recording of the test as well which can be referred to for later usage. The observations of the flow of the game as well as how the user is reacting to the game are important to note down. We ideally want the game to be easy to use and motivate the user to play more and improve their scores therefore the user’s reaction to the game is a very important observation to note down.

Expected Outcomes

Best case: We expect the test subjects to accomplish all the usability goals without requesting the help or answer. Also, the test subjects become interested and motivated during the testing.

Worst case: Worst case would be the case that the test subject partially or does not complete the usability goals and frequently ask for the help and request the assistance to examiners. And, the test subjects does not want to engage in testing and feel bored about the game play.