Briefing
"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."
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
The following tasks were added for the second iteration:
Task 5: An event you're attending has been updated. Find out what has changed. (Check your notifications)
Task 6: Edit your profile
Task 7: You want to go to the windows 7 party, but you're busy then. Browse other events in the Tech group
Prototype photos
We took pictures of our final iteration. The photos are divided roughly by task.
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
Task 5: An event you're attending has been updated. Find out what has changed. (Check your notifications)
Task 6: Edit your profile
Task 7: You want to go to the windows 7 party, but you're busy then. Browse other events in the Tech group
Observations
We had the chance to work with six users in the first round and three in the second. In the first iteration, the usability problems our users encountered were largely due to confusion about minor points of the interface. User 3 was confused about the "all day" checkbox on the event creation page, and was concerned about the lack of content in the main frame of the friends page - initially the main frame was empty and the only content was a list of friends in the sidebar. This was ameliorated with the second iteration, as we added content to the main frame in the form of a list of friends' events. User 5 was confused about the process of adding friends to an event, which seemed to spout from the improper wording of our directions. We changed "add friends from toolbar" to "add friends from sidebar" as per User 6's suggestion, and there were no further questions or difficulties with adding friends to events.
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.
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.
Overall, I think we learned more in building the paper prototypes and identifying what tasks to test for then we learned from user feedback. Part of the reason for this is because we had come up with three very different designs in GR2, so the process of making design decisions and compromises really helped us settle on a single vision for the project. The other major reason is because we had tested the tasks on each other before we ever showed the prototype to a user in class. This meant that we had already worked through a lot of the design kinks that our original designs in GR2 did not handle. That said, we did get some great insights during testing in class, especially with regard to spatial placement of different elements on the page and the some page navigation approaches that none of the team members had really considered.