6.813 GR-6: User Testing

Group Order

Michael Grinich
Salman Ahmad
Jana Yamani

Design

One of our main goals for this application is to make it compatible with different devices.  Below we present the interface on an iphone and a computer. We also present the different features and the reasons behind these choices.

Overview screen

When you go to GroupOrder, the first thing you see is a clear step by step process of how this app works. During the paper prototyping we got positive feedback on this as well as the big red button and how easy to notice its clickability (red button = clickable). Our intentions back then was to make it clear for the paper prototyping user that anything red can be clicked. But we ended up carrying the red button with us to the computer prototype where this became the signature design of this app.

Navigation Bar

The navigation bar was one of the parts that we iterated on the most. We initially had the following

We realized two things with it: 1) It did not scale well with the resizing of the screen, and 2) people were perceiving gray as something which is incomplete or inactive (This was one the comments in the heuristic evaluation).

We then decided to use the red color for the active tabs. We solved the scalable problem by changing to a different tab that takes less length when the window resizes to a certain size.
Hence, the navigationbar  type depends on the device you’re using or the size of the your screen.

The other decision we had to make is whether it should be clickable or not. We have been looking around and saw that many online navigation bars were unclickable. We wanted to carry this external consistency and do the same.

Truck selection

As mentioned before, the results from the heuristic evaluation showed that users perceived gray as inactive and red as active in our app, hence, we decided to gray out temporarily unavailable truck. In addition, we also added a note that says “coming soon” if people end up hovering over it or were willing to click on it for a better system feedback.

Menu/Order Page

We also iterated considerably on the method of selecting quantity. Our original interface, shown below, had a [+1] and [-1] button. After user testing, we received the feedback that it was unclear what these buttons did and users were unsure how to remove an item. We originally thought this had to do with the ambiguity of +1, so we changed the label to an up arrow and down arrow. However, this was even more confusing in that the arrows appeared to somehow control the vertical arrangement of the table. Not good.

Tangential to this, we also discovered the issue that when incrementing quantity, the only visual response was the item quantity value under the right “Your Order” section. Users would click on the left side of the page, and not receive any feedback visually close to the button. This was even more so an issue on mobile devices, where the “Your Order” section would be positioned below the entire menu by our fluid layout. In this system, users would have to click to add an item, scroll down to confirm it was added to the cart, scroll up, and continue shopping. Also, not good.

We solved these problems with two changes. First: we added a flashing yellow background when incrementing the order, which gives a large amount of visual feedback that an action has been performed. This is so natural, that many users don’t even notice it happening. Secondly, we combined both columns into one list, displaying the quantity directly next to the buttons which modify it. We also combined both buttons to a segmented control, and returned to the +/- naming convention. We found this to be incredibly effective, as their context described the behavior much more naturally.  We also removed the itemized cost total as unnecessary information unrelated to making a purchasing decision.

This visual simplification led to quicker ordering and much more natural user experience. It also solved the tap-scroll-check-scroll on mobile devices.

Initially had +1/-1 and two columns

Changed buttons to up/down arrows

Order confirmation & validation

We also added a required field for name, as well as 10-digit phone number validation for the mobile number in almost any format (supports hyphens, parentheses, etc.).

Confirmation

After our heuristic evaluation, we added more information to our order confirmation page. Many users were unclear about what happens when their order was placed and how to contact the site to change an order. We added a phone number to call for questions, which is how we imagine support would be handled for this service with an alpha launch.

Previous screen

Implementation

GroupOrder is a single page Web application using HTML, Javascript, and CSS. The different parts of the user workflow are dynamically shown and hidden using Javascript.

We initially designed it this way to make our computer prototype easier to develop. We just threw a single “index.html” file into Dropbox, started hacking, and didn’t need to worry about creating a templating engine to maintain consistency across different pages. However, later on, we realized this improved the user experience a lot because the application was (obviously) much more responsive. This is particularly true on mobile devices where waiting for a next page to load is often frustrating. Instead, our content appeared the instant the user pressed the “next” button. The downside to this was that users often expected the browser’s back button to take them to the previous step, which did not work. To solve this, we made use of the onhashchange event to capture the back and forward buttons.

Later on in the implementation we moved to a lightweight Javascript templating system called Handlebars.js. Typically in a Javascript application, the developer manages the DOM on their own using callback functions. For example when a user clicks a “+” button, the developer would provide a callback function that manually increments the “quantity” label by setting its “innerHTML” attribute. The problem with this approach is that it often results in difficult to manage “spaghetti code” leading to subtle but problematic usability problem - for example the quantity label may get out of sync. We prevented this problem by using MVC-like organization on the client. A cornerstone of this organization was Handlebars.js. Whenever an event took place we would update a model and re-render the entire screen using the appropriate Handlebar template. This ensured that everything stayed consistent and greated facilitated our development.

The full list of the technologies used include: HTML5, Javascript, CSS5, jQuery, jQuery UI, Twitter Bootstrap, Handlebars.js, and Google Web Fonts.

Evaluation and User Testing

User Test Process:

Our target audience are people within the MIT community. So for this test cycle we chose MIT graduates and undergraduates. The test starts with a one minute application brief, then users were asked to carry on a task.

Briefing:

GroupOrder is a website designed to allow people to order food for delivery from food trucks at MIT. We are going to ask you to carry out a task.

Tasks:

1. You are at the Media Lab and you decided to order the following from clover: 2 Soy BLT Sandwiches, 1 Coffee, 1 Egg & Eggplant Sandwich.
2. You are at the Media Lab and you decide to order the following from Clover: 1 BBQ Seitan Sandwich. After arriving at the “checkout screen” you remembered  you’ll be in Stata at 12:30, so you decide to change the location for delivery.

3. Being a nice person, you decided to get lunch for yourself and your friend delivered to the Koch building. You want to order an Parsnip Cheddar Sandwich from Clover. Your friend, on the other hand, wants to order the City Beef  from City Wok.

Observations:

Tester 1: (Task 1)
This tester ran the application on a laptop. He thought the application was very clear, smooth and easily usable. His only comment was that since he’s using a widescreen the distance between the menu items and +/- buttons was too big. However, when he resized the browser screen he was satisfied by the adjusted distance.

Tester 2: (Task 3)
This tester ran the application on a laptop. She added the first order from Clover, then went back to the truck menu and saw that the order was emptied when she chose the other truck. At this point, she was confused and asked whether she can add items from different trucks to the same order. She then realized she needed to create 2 separate orders. At the end of the task, she mentioned that the navigation of the application was nice but she would’ve loved to be able to order from different trucks with one order request.

Tester 3: (Task 2)
This tester ran the application on the iphone. Everything went well until the tester was asked to go back and change the location. He was not sure which navigation step was the location, so he had to go back a few steps until he found the location. He mentioned that it would be clearer if all navigation steps were titled, instead of the current step only, because this way you know exactly how the steps are organized and what’s coming next. Also, he mentioned that at first, he did not notice the small toggle that maps the title to its step location because of its small size, it would’ve been less confusing for him if the toggle was clearer to see.

Usability problems:

Reflection

One hugely important aspect of our iterative process was focus. Early on, we decided to pick a seemingly simple problem (group food ordering) as our design topic, while others in the class were choosing more ambitious ideas. We wondered if this would mean it would be too easy to come up with a solution.

Thankfully, we were wrong. Though simple on the surface, this problem presented an array of complex choices once we started implementing and testing our designs. Positioning, interaction, mental models, task flow, symbols, and more presented more than enough variable to tweak and adjust.

By focusing on only a handful of features, we were able to iterate several times and come to very considered solutions for all of the issues which arose. For decisions like where to place quantity buttons, it took at least a dozen different designs spread out over weeks before we settled on a good solution.

Prototyping using a shared Dropbox folder and quick Google Chat communication allowed us to split up the world and implement sections separately. Our group meetings were very focused, since we created a list of issues to discuss before the meeting. Similarly, our design and prototyping meetings were driven by producing new designs or features to implement and test. Structuring our time and interaction like this allowed us to work faster as a group, and therefore spend more time designing and solving problems.

In terms of feedback, we spend more time observing users than asking them what they wanted or what they thought. By observing carefully, we were able to actually see what they wanted to do or were attempting to do. Simply asking users what they wanted would have never led to our final design. After all, it's our job-- not theirs-- to design the product.

If we were to change anything over, I think we would have moved past the paper prototyping phase sooner and allotted more time for computer prototyping and iteration. Many of the problems that arose during the paper prototype testing were related to the medium and not the designs. The exercise was useful in terms of quickly running through initial designs, but the time to actually test those designs with several subjects could have been spent better elsewhere. Because of our technical background and the ease of HTML/CSS tools, we found developing a computer prototype to be comparable, if not faster, than designing a non-interactive paper prototype.