Lab Exercise : User Testing

Each team should set up a few computers running the latest stable version of the project for other students to user test. Any issues discovered or improvements considered based on this feedback should be prioritized in the context of the project's Backlog, its complexity, and the amount of time remaining in the project rather than simply done right away.

In general, here are 10 Usability Heuristics that provide clear guidelines for ensuring your UI does not suck :)

Submission

At the end of lab, one person should push a file named doc/USER_FEEDBACK.md to the ooga_teamNN Gitlab repository to submit the team's summary of all the user feedback and the team's ideas for addressing any issues raised. Make sure the Title of your commit is of the form "lab_user_testing - participating NETIDs".

User Testing

Letting potential users interact directly with your project early and often, while some changes can still be made, is a vital part of the agile process. User feedback can be ambiguous or even contradictory, so deciding how to respond to the feedback will likely require a team discussion (or, in the real world, a decision by your client).

Note, to get a variety of feedback, a team may ask users to try different specific tasks or features within their project.

Everyone should take a turn being both a facilitator and a user:

• A facilitator stays with a computer to record feedback from users, while saying as little as possible
• A user visits another team and tries playing their games (and perhaps trying to create a new game), talking about it as much as possible (such as any issues you have doing or finding something, any bugs, or anything you especially like)

During the test, each person should work to provide as realistic an experience as possible:

• Users should try to think aloud while they work, i.e., verbalize their thoughts as they interact with the project (the goal is to keep a running stream of consciousness as you work)
• Facilitators should only answer specific questions from users, but not to explain how to use the project
• Facilitators, after the test, should ask for general impressions of the project (especially first impressions, what worked, and what could be improved)

After the tests, as a team, discuss the feedback users gave and how you plan to address any issues that came up that do not have an obvious solution (i.e., not bug fixes or simple changes).