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.
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.