1. 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. 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. 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 for Iteration 1:
LunchBunch is a website that allows users to easily coordinate group lunches through an invite system. For the purposes of this test, we will assume you have already set up an account and added friends through the service. This invite screen (screen 1) is the first thing you see upon opening the website.
Briefing for Iteration 2:
LunchBunch is an Android app that allows users to easily coordinate group lunches through an invite system. For the purposes of this test, we will assume you have already set up an account and added friends through the service. This invite screen (screen 1) is the first thing you see upon opening the app.
Iteration 1:
Task 1- You want to go to lunch, check out your options. You're interested in the Taco Bell lunch, but before accepting, check your other accepted lunches to make sure you're free.
Task 2- Join the Taco Bell lunch
Task 3- Unjoin the Taco Bell lunch
Task 4-Create the following lunch:
Cosi, Monday 4/9/12, 11:30am
Invite some, but not all, friends. Set an email reminder for 30 minutes before. Don't request confirmation. Make a comment.
Task 5- You just got an email, check who is attending the lunch and then confirm your attendance.
Iteration 2:
Task 1- Browse the lunches you are already planning on attending.
Task 2- You remember seeing a Taco Bell invite, accept it.
Task 3- On second thought, you don't want to go to Taco bell. Unjoin the lunch.
Task 4-Create a new lunch for Cosi on 4/9/2012 at 11:30 am. You want a reminder 30 minutes before the event.
Task 5- You see a notification from LunchBunch. Attend to it.
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.
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.
We also realized that this application would be most useful as a mobile app. Originally we planned for LunchBunch to be an internet site, so we had a lot of information per page (especially on the “Create New Lunch” page). When we redesigned the UI to be a mobile app, we had to be consistent about including buttons that prompt the user for a decision on the top of the screen (e.g. “Done”, “Attending”, “Not Attending”, "Confirm"). We also had to make sure that no page was too long because the user shouldn’t have to scroll much on a mobile app. That meant splitting up the lunch creation process into two screens: the first one asks for event details and the second allows the user to invite people. As a result, each screen contains approximately the same amount of information and fits on one screen. We also made it easier to create a new lunch by just clicking on the “+” icon at the bottom of the list of lunches on the “Lunch Invites” and “Lunches I’m Attending” screens.
Because we turned LunchBunch into a smartphone app, we replaced the email reminder/confirmation request with a push notification that pops up on the phone. We also simplified the confirmation request to come along with the reminder so that users aren’t receiving two different types of notifications at different times. After the second iteration, they will either receive a reminder or a reminder with a confirmation request. Clicking on either type of notification will take the user to the event details page for that event but if a confirmation was requested, there will be a “Confirm” button at the top of the screen.
We stopped asking users to check for a conflict with a new lunch invite as a part of their tasks because we considered the fact that users will mostly be using this app to create lunches that are at most 2 days away. Most lunches between co-workers and students are planned the day before or the morning before the lunch. Thus, it's unlikely that conflicting lunches will be a problem for the user that the UI needs to take care of. Instead of better indicating a conflict on the "Lunch Invites" screen, we plan to show them a message if they accept a lunch that conflicts with another lunch in the "Lunches I'm Attending" list. However, most people know their short term plans and would most likely already have an idea if they have a conflict or not. Also, the easy navigation between the "Lunch Invites" and "Lunches I'm Attending" pages makes double-checking lunch times easy enough for the user.
As a result of the changes we made, the second iteration of the paper prototype was much simpler and easy to navigate than the original design. This simplicity makes the UI very appropriate for a smartphone app.
