Prototype Photos
1. 2. 3.The user starts at the invites page to browse current options 2. If the Taco Bell invite is clicked, the user sees the details 3. After selecting "attending" from the details page, the lunch is added here
4. 5. 6.If you navigate back to the details page, you have the option to 5. If you select "not attending" the lunch is no longer in the 6. To create a new lunch, click the "+" on the "lunches I'm attending"
select "not attending" "lunches I'm attending" page or "lunch invites page" to navigate to this form
7. 8. 9.After filling in lunch details, invite guests 8. A newly created event is added to "lunches I'm attending" 9. At the appropriate time, a push notification reminder will popup on
your phone
10. Clicking on the notification will allow you to confirm your 11. Example Task Card
attendance.
Briefing
Briefing for Iteration 1:
...
Task 5- You see a notification from LunchBunch. Attend to it.
Observations
Iteration 1:
During our first iteration, some users had some trouble understanding that “Lunch Invites” are merely invites to lunches. These users thought the page they were seeing represented their actual lunch schedule (i.e. lunch invites they had previously accepted). We attributed this to unclear wording in the instructions to the users. After we changed the wording of the task, no further users had this issue.
Some users during this iteration were unclear of the differences between email reminders and request confirmation emails (lunch creation page). As a result, we have decided to combine these two notifications. Emails would simultaneously ask users to confirm their status, as well as remind them of the upcoming event. Event creators still have the option of refraining from asking for confirmation. In this case, the email would only serve as a reminder to attendees.
Users indicated that the app would be more useful on a phone, and that the user interfaces are simple enough that a mobile platform is plausible. We have decided to take this into consideration, and our project is now a mobile app for Android phones.
Users also showed that they were confused by one of the tasks in which we asked them to confirm that a lunch invite they were accepting did not conflict with other lunches they had already joined. The purpose of this task was to see if the user could easily figure out where their accepted invites vs. their pending invites are located. Due to user confusion, we decided to remove this "identifying conflicts" task. Having the app find conflicts automatically was a proposed solution, but we decided that is not a UI issue.
Users also expressed that the confirmation emails should have all lunch details inside the email instead of requiring the user to click to a link on the website. This point is irrelevant because our project will now be a mobile app, and push notifications will be used instead of emails.
Iteration 2:
Our second set of user tests were much more successful than the first. The main point of concern during this iteration was in the wording of some of the labels and page titles. Namely regarding whether "lunches" in the context of the app should be viewed as events to attend, or invitations to accept or decline. In testing, the consensus seemed to be that the current "join" and "decline" options seemed awkward and that the label "my lunches" was vague. We changed the wording to be more consistent using the "attending", "not attending" pair and in further tests, these changes were well received.
We also tested how well users understood our concept of asking for confirmations when creating an event. It seemed like users understood that the app would be asking for confirmation from guests prior to the event, but it was not always clear that the confirmation request would come with the reminder or that the reminder would come in push notification form rather than email. In response, we changed some of the wording on the "create new lunch" page
Another focus of our second set of tests was in seeing how users interacted with our new android app prototype as opposed to our initial web app prototype. Navigation in this form seemed to be smoother and our pages were less cluttered than in the first iteration.
Prototype Iteration
We found that users found it slightly difficult to navigate between the “Lunch Invites” and “My Lunches” pages. They would also look for lunches they were attending in the “Lunch Invites” page. In order to make this navigation more clear, we renamed “My Lunches” to “Lunches I’m Attending” and put an indicator in the corner (ex. “Lunches I’m Attending >”) that shows that the phone screen can slide to reveal the other page, or clicking on the indicator can also take the user to the other page. We then changed the wording so that users are “Attending” or “Not Attending” a lunch rather than prompting them to choose “Join” or “Decline” because users were confused what “Decline” would mean when they were trying to un-join a lunch.
...