GR6 - LunchBunch User Testing

Design

The purpose of our application is to allow users to browse lunch invites, respond to lunch invites and create new lunches. For simplicity, we chose to limit the main navigation to two main tabs: "Lunch Invites" and "Lunches I'm Attending". Lunch Invites have 4 states: declined, accepted, confirmed(if it has been requested by the creator), and unknown(for those invites to which you have not responded. Accepted invites and subsequently confirmed invites appear on the "Lunches I'm Attending" page. Invites to which the user has not respond or has declined appear on the "Lunch Invites" page. Both these pages are set up as browseable lists. The user may click on a particular lunch to view its details. For this general design, the biggest gain from user testing was in the wording  in our application. We went through multiple iterations of labels for the tabs and labels, eg. "joined", "my lunches", "unjoined", etc. before deciding on the set that made the most sense to the most users.

Figure 1: Image of the application when first           Figure 2: Image of the Lunch Details page. Initially,

opened.                                                              a user may choose to "accept" of "decline" and invitation and

                                                                         as the status of the lunch invitation changes, the buttons in the

                                                                         top right hand corner will be modified accordingly.

A notable feature of our design are event reminders and notifications. If, in creating a lunch event, the creator chooses to send reminders to invitees and optionally also request confirmation, a push notification will appear on all invitee phones at the pre-determined time. We chose to implement notifications in this fashion to be externally consistent with other android applications. Similarly, other features of our application, such as the hardware back button and the text and calendar forms, perform operations identical to those in other android widgets for better learnability.

Figure 3: An android push notification. These notifications alert

the users of new invites and reminders for accepted lunches

Clicking on this notification will take the user to the appropriate

event details page.

From either the "Lunch Invites" or "Lunches I'm Attending" page, the user may choose to create an lunch invite of his/her own. Creating a lunch invite involves a two step process which, through our user testing, we refined to be as simple as possible. Conciseness and clarity were particularly important to ensure that all the necessary information was gathered from the users, and that the small amount of UI real estate on the phone was used as efficiently as possible. Multiple backend checks were built into the create lunch forms to avoid errors (such as lunches set to times that have passed) and some parts of the UI adapted as the users inputted information (for example, if no reminder was requested, further prompts about reminder and confirmation settings were hidden).

Figure 4: The create lunch form requests               Figure 5: After the user clicks "Done" on the create

information that is included in lunch invites            lunch form, they are prompted to select invitees to whom

and is responsible for setting up reminder             lunch invites are sent.

notifications and confimation requests.

Implementation

Implementation was quite straightforward using the Android SDK. However, it was a challenge to set up the layout of the pages using the small set of provided Android layouts that we could use. It was also hard to ensure that the screen layout was compatible with multiple screen sizes. We ultimately chose to make the layout compatible with about 80% of Android screens currently in use, which excludes extra large screens and tablets.

Unlike most apps, our app did not have a server to help mange information in the backend. Therefore, we had to pass information from screen to screen to make sure that the app did not lose track of it, which created a sort of “fake” backend. This would not be the implementation approach we would take if we actually implemented this app. Since there was no real backend, there was no way for one user of the app to invite or receive invites from other users. We created a reminder and a lunch invite notification that would go off 1 or 2 minutes after the app started running in order to simulate receiving a reminder and new lunch invite to the user.

Reflection

We found that our UI changed dramatically from the paper prototype to the computer prototype. This was because we were limited to styles that were provided by the Android SDK and we had not considered how limited the screen space was on a phone. However, the paper prototype step was very helpful because it forced us to decide on our scenarios and ensure that it was easy and intuitive for the user to complete the target tasks.

We were not able to prototype some key touchscreen interactions using the paper prototype, so during the computer prototype we made the decision to add tabs to toggle between pages instead of having the user swipe to get between screens. There was no indication on our UI that the user should swipe to change screens, so we changed the UI to feature two large tabs at the top of the screen.

In general, we tried to follow UI designs that were already very common on phones to ensure that users know how to interact with our app. For example, selecting friends to invite to a lunch on our app is very similar to the way you select friends on Facebook. We observed that some users were confused what it meant to “confirm” attendance to a lunch once they had already accepted the lunch, so we added a line of instruction that informed the user that confirmation of their attendance was being requested. This made it more clear to users that there was a difference between simply accepting a lunch and confirming it as the lunch is approaching and you get a reminder.

Evaluation

Users were found around a dorm at MIT who were studying a variety of majors. All users were smart phone users. We had 4 users evaluate the app (3 male, 1 female) from ages 18-21 (median = 20). Users were given a description of the app and told to perform certain tasks as well as keep an eye out for notifications. The users were asked to:
1) Browse their lunch invites and accept/decline lunches as they wished.
2) Create a new lunch
3) Respond to the reminder and new lunch invite notifications

Users were able to complete tasks 1 and 2 very easily. There was occasionally some hesitation on what to do after accepting a lunch because the lunch leaves the “Lunch Invites” tab and goes into the “Lunches I’m Attending” tab. However, users found navigating between the tabs easy so they could quickly understand how lunches moved between tabs.

Users that were not used to an Android phone had a harder time noticing the notifications pop up. Looking into the header for notifications is something that Android users are used to but iPhone users ignored. We had to alert one user to check the notification because he or she wasn’t aware it had come and didn’t know how to check the notification by dragging down the top header of the phone. This is not an issue that we can fix because it is native to Android phones. However, since this is an Android app, only Android users will be using it and won’t run into this problem.

Users weren’t confused about confirming their attendance to an event once they got a notification, as they were in previous user testing iterations. However, we had to explain to them that this was an invite they had already accepted and now they were getting a reminder/confirmation request for it. Once we asked them to respond to the reminder, they understood they had to confirm their attendance. If a user was using the app, they would understand on their own what the lunch was because they would remember having accepted it.

Some users confused the “Cancel” button for a button that would take them back to the previous page rather than a button to cancel the lunch because they were the creator. We had a dialog box pop up and ask the user if they were sure they wanted to cancel the lunch, so the users didn’t accidentally delete a lunch when they just wanted to go back. However, to avoid this problem entirely, we should make it more clear that the lunch was created by you and therefore you have extra control. The button should also be renamed to “Delete” or “Cancel Lunch” so the users don’t think they are cancelling the page. Also, putting the “Cancel” button next to the “Edit” button might make it more clear that these are buttons that change the lunch.