Prototype Photos
1. 2. 3.
4. 5. 6.
7. 8. 9.
10. 11. Example Task Card
Briefing
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.
Scenario Tasks
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.
Observations
Iteration 1:
Users during our first iteration had some trouble understanding that “Lunch Invites” are merely invites to lunches, they do not represent your actual schedule. We attributed this to our user test task wording to be unclear, and upon clarifying there were no issues with further users.
Users were often unclear of the difference between an email reminder and a request for final confirmation of attendance, so we have decided to combine these two things. (An email that does not request confirmation is still an option).
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.
Iteration 2:
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.
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.