GroupOrder - GR3

Paper Prototyping

Prototype Photos

Select photos from our prototyping session are included here. We have pictures of each stage of our application in addition to before and after pictures between our iterations. We also recorded video of all of our sessions, but did not include those here to preserve the privacy of our testers.

Flow through the application:

Changes:

Briefing

EatTogether is a website designed to allow people to order food for delivery from food trucks at MIT. In a minute, we are going to ask you to carry out a couple of ordering tasks. However, first we would like to ask you a couple of background questions:

- What do you usually do for lunch?
- Have you eaten at the food trucks?
- If so, which ones? Which is your favorite?
- How often do you eat with friends?
- Do you eat with your research group? If so, how often?
- Do you ever skip lunch? If so, why?
- Do you order food online? (CampusFood, GubHub)

Scenario Tasks

Task 1:

You are at the Media Lab and you decided to order the following from clover: 1 BLT Sandwich.

Task 2:

You decide to order the following from Clover: 1 BLT Sandwich. After arriving at the “checkout screen” you decide to change your mind and try to find another entree that is cheaper.

Task 3:

Being a nice person, you decided to get lunch for yourself and your friend. You want to order an Egg & Eggplant Sandwich from Clover. Your friend, on the other hand, want to order the Tofu & Noodles from Ramen House.

Task 4

Similar to Task 1. It replaced Task 1 in our second round of prototyping. The reasons are discussed below.

You are at the Media Lab and you decided to order the following from clover: 2 BLT Sandwiches, 1 Coffee, 1 Egg+Eggplant Sandwich.

Observations - Round 1

User 1

This user eats from the food trucks but prefers eating at Stata for lunch. The Asian Bistro truck is his favorite lunch truck. The user usually eats lunch with friends but not his research group which is made up of 3-4 people. Sometimes however, the user skips lunch because of conflicting meetings. Ordering online for dinner is a usual activity that the user does.

Overall, the user’s interaction with the interface was smooth. He even commented about the coolness and easiness of the interface. In some cases however he got confused by whether some objects like the upper arrows were clickable. Also, the user made assumptions that the personal information section in the checkout page is saved. After submitting the first order in Task 3, the user showed his concern about not wanting to post to Facebook but then realized that its optional.

User 2

For lunch, this user eats from either Forbes cafe at Stata or the food trucks. He has tried all the trucks, but usually eats from either Clover or the Falafel truck. The user usually eats lunch with friends and infrequently with 2 of his research group. A couple of times a week however, the user skips lunch. The user has only tried ordering food online from a service in New York.  

The task was straight forward and very simple to do, as said by the user. The user did not have any problems and executed the tasks perfectly. When attempting to edit his order from the confirmation page, the user did attempt to remove items from the confirmation page instead clicking the “Edit Order” button to go back to the order page. At some points during the task, the user did ask and seem to expect that the “bread crumbs” at the top of the page were clickable when they were not. However, this did not impact their task performance.

User 3

Overall, the user thought the interface was pretty intuitive, but has to ask for help to complete Task 2. When the user had to delete one the dishes in the cart, he pressed the wrong button, the x corresponding to the quantify (for example “1 x Coffee”) instead of the x for the deletion button. Also, after going back to the menu and realizing that there is no entree cheaper than $5, the user did not know what to do. He was then assisted by the facilitator to see whether there are other trucks. From there, the user was able to complete the task. He mentioned in the end that he would’ve clicked on the upper arrows, but assumed it’s not clickable because its not red.

Prototype iteration

We realized that at the end of the workflow, users were confused at how to get back to the main screen. So, we simply added place another order button.

We realized that a short coming in both our scenarios and our UI did not have the ability to add more of one item. This was a silly oversight in our original UI design so we changed Task 1 to incorporate multiple items and then added a quantity column next to the items on the order page.

Users were also confused at how to remove items from the confirmation page. We changed the UI so that users were no longer able to edit their order form the confirmation page. Instead, they had to go back to the order page and edit from there.

Observations - Round 2

User 4

For lunch, this user either buys food from the Asian truck or places around Kendall square.  The user usually eats lunch with friends. A couple of times a week however, the user skips or delays lunch because of either waking up late or classes. The user has tried ordering lunch and dinner online from CampusFood.

The user executed the tasks successfully but was concerned by the usability with Task 4 (task 1 edited) regarding the of the up and down arrows next to the order. She did not realize that the box indicating the number of order for the dish was an editable one, and thought it will be hard to order as much as 10 orders from the same dish by clicking the up arrow 10 times. Notably, the user was asking whether the pick location can be changed for a delivery from a certain food truck.

User 5

For lunch, this user usually eats at the student center. He used to order from the falafel truck but not anymore. The user eats lunch with friends at the student center. Sometimes the user divides his lunch and eats twice depending on his daily schedule.

During Task 3, the user started by ordering for his self, then before submitting the order, the user went back to the other trucks menu to order for his friend. However, he then realized that his previous order was deleted. He then did 2 separate orders for him and his friend. The user assumed the idea of a shopping cart with this interface, where any added item to the shopping cart remains there unless deleted by the user. The user said that after realizing that it is not the case, then the rest interface was simple to grasp, but the initial mistake seemed like a pretty big disconnect.

User 6

Overall, the user did some back and forth steps to accomplished the tasks, especially Task 2. In the task, the user had to delete the item added to add a cheaper one. The user had to go forth and back to check the amount of the item to make sure the new one selected is cheaper. For deleting the item, the user was confused as to whether he should press the “edit order” or the x button to remove the item.

Take aways and ideas for improvements

Overall, users found the general interface simple, intuitive and easy to use. The main difficulties the users faced had to do with the impoverished affordance of the paper prototype.

Learnability appeared to be high. Most users seemed comfortable with the interface that felt like most other commerce sites they have used before. Small mistakes were made by users (we ignored any slips), however, nothing that was permanent.

We did come away with a couple of idea that we want to explore more.

First, the quantities was confusing to some users, even after our redesign. One thing that we should think about is having an explicit, table-like “Qty.” column instead of the “x”. In addition, instead of having a text box for the user to input a quantity, we should think about of just having a plus  and minus button. The plus button appears on the “Menu” column on the page and the “” button appears on the “Your Order” column. If users want to order multiple items, they just tap the ""  the desired number of times. If they want to remove items from their order, they tap the ""  button which decrements the quantity. When the quantity get to 0, the item is removed. The nice thing about this, is that there are no more "x"s in the UI. The downside to this is that the U is that users users may "overshoot" their desired quantities. However, our guess is that people are not going to be ordering large quantities of good so error prevention is likely not that big of a deal in the common case. Additionally, having easy to click "" and "-" button is certainly more efficient for smaller quantities than clicking in a text box, moving your hand from your mouse to your keyboard, typing the number, hitting enter, and moving back to your mouse.

Second, After talking to a couple of users, we came away with an idea for a “Unified Shopping Cart”. Right now, our application flow is: (1) choose truck (2) select items (3) place order. To accomplish Task 3, this would require the user to place 2 order to get items from two different trucks. One idea is to have a “Shopping Cart” model, where users can choose their truck and add items to their cart. The items in the cart remain even after the user changes to another truck. Once they are done, they are able to place just a single order. This model will retain the same “ease-of-use” as our current implementation, but will scale better for scenarios like Task 3. This does come at the expense of a more complicated back end (and handling payments to multiple sources) but since this is a UID class, we should not sacrifice user experience because of implementation difficulties.

Third, following the difficulties of User 6, we did realize we should add strong cues on the confirmation page that the order is not editable and that the users need to click, “Edit Your Order” to go back and make changes. We felt that the problems of User 6 was due to the low fidelity of the paper prototype.