...
"This is EventHub. It's a website for finding, scheduling, and posting events in the near future in your vicinity. So for example, if you have a couple hours to kill after class, you can come here and find something cool to do; or, if you want to organize a dinner with friends, instead of emailing everyone and juggling replies, you can organize it here. You're entering this situation in the middle of a user 'state': you already have friends, events in your calendar, all that. We're going to give you some tasks a normal user would do, and it would be helpful if you would think aloud while performing these tasks. You are free to leave the user test at any time."
Scenario Tasks
Task 1: You're going to a basketball game today; let people know you'll be coming late
Task 2: Create a chess game at 6:30 today
Task 3: Find friend Sara, check out her profile
Task 4: Reschedule chess game
...
As we iterated our prototype, we tried to fix these problems and further improve and expand our application. While the problems of the first round did not crop up again, the expansion brought new problems into the mix. In an attempt to make it more clear that the "friends" tab included more than just friends (other people and the user's own profile), we changed the title to "People". However, this seemed to cause more problems than it fixed: users hesitated much more in this round when trying to find their friends. Furthermore, we implemented a notification system in this iteration that needed tweaking as we tested on users. Initially, users couldn't find their notifications, but by making them much more visible, they began to click on them even before we gave them a notifications task, exactly what we wanted. The only major problem that persisted in this iteration was the content of the friends/people main page. Instead of a blank page, we had a list of friends' events; however, at least one user thought he was returned to his own calendar and thought he had clicked the wrong button. In our computer implementation, we will seek to make it more obvious that the user is in the friends section.
Another interesting observation was that a couple of users struggled with Task 2 ("Create a chess game at 6:30 today") -- not because of the interface, but rather because the users were just unsure of what to fill in for the rest of the form fields. For our paper prototype, we had decided to focus more on navigating to the form than filling in the form because the usability of a form is so dependent on whitespace/color/contrast/consistency. In testing, we expected everyone to just make a typing motion with their hands for fields we hadn't provided and say aloud "end time", "location", etc. We didn't want to bog users down with information that wasn't really necessary to this stage of our testing. Some users, however, seemed really worried about these fields, and asked us what to fill in for them. We learned that people hate making decisions, even if they are decisions that don't actually matter.
Prototype iteration
We had a fairly successful first iteration in terms user feedback and task completion rate. Ironically, that left us in a bit of a difficult situation for determining what changes to make for the second iteration. The first thing we decided was to include additional features to our prototype by incorporating groups and notifications. We then created a few additional tasks to test these features, shown in tasks 5-7, above. Also, we added the use of sticky notes to our paper prototype to dynamically show updates that occurred to a given page and for notifications.
...