Paper Prototype

Anthony Chen, Andrew Cooper, William Stueck

Prototype photos

Briefing

The purpose of this application is to help users find restaurants on the fly. The application is designed with the following user in mind:

• The user wants food now, with utilitarian purpose in mind.
• The user is not very familiar with the restaurant landscape in the immediate area.
• The user is not sure what kind of food he wants right now. He just knows he is hungry.

A user of this application should be able to accomplish the following:

• View restaurants in the vicinity
• Select restaurants to compare against each other
• Choose a restaurant to go to
• View a map to navigate to that restaurant

This application is designed as a mobile application, and you can consider yourself to be searching for restaurants on an iPhone or similar mobile device. Keep in mind that the device is a touchscreen and that these devices typically do not have hard keyboards.

Scenario Tasks

Our scenarios researched decision making at two different levels of comparison. Scenario 1 analyzed the user's behavior when four options were narrowed down to two, at which point a decision was made. In our second case, we tried to observe the case where a user was able to make a decision from the initial four choices, assuming the information provided at that level was able to inform the user. During testing, we alternated the order for each scenario so that each scenario would observe a user learning our application for the first time. 

Scenario 1

1. Analyze the restaurants presented
2. Discover that you are deciding between Chik-fil-a and steve’s
3. Compare multiple menu items from both restaurants
4. Eventually discover that you want to go to Steve’s
5. Discover how to navigate to the restaurant

Scenario 2

1. Analyze the restaurants presented
2. Eventually discover that you want to go to Steve’s
3. Discover how to navigate to the restaurant

Observations

Round 1

• Users did not recognize that each of the four restaurant tiles acted independently of each other.  Users tried to scroll through restaurants they didn’t want but were surprised when a single gesture only replaced a single option on the menu.
•  Users did not understand that if they swiped one restaurant away, it would be replaced by another, and that was the way to cycle through restaurants.  They learned that this was the functionality after making 3 mistakes on average (2, 3, and 3 mistakes on our three users, respectively).
• Users learned quickly that each restaurant is independent of the others, and that it can be manipulated alone.
• Users tried to compare restaurants by clicking on individual restaurants.  This unexpectadly led them to the map screen, even though they were not ready to commit to that restaurant.
• No user successfully swiped two items away to get to an in-depth comparrison.  The side-by-side comparrison went unused even though we instructed our subjects to use that functionality
• The only way they figured out how to compare was by selecting an item, seeing its full menu and map, and then using the back button.  This was not our intended use.
• Users often searched for a compare button.
• Users expected there to be some sort of “compare” tick box on items they wanted to compare, in consistency with other applications that allow compare.
• One user complained that our application forced him to use his phone in landscape orientation, and he didn’t like that.

Round 2

•  Users understood that each tile was independent of each other tile after they were “dealt” when the application opened.
•  Users still did not understand that they could swipe restaurants away to find new ones.  They learned this after they made one mistake.
•  Users still instinctively clicked on restaurants they were interested in.  This time that pulled up the menu for that restaurant, leaving the other three options on the other half of the screen.
•  Users understood that they could tap one of the other three restaurants to get a side-by-side comparrison.
•  Users were unable to figure out how to get from the screen of four elements directly to the map of a single restaurant (double-click).
•  Users compensated for this by travelling through the menu of the restaurant they wanted, which took one extra click.
•  One user thought that if he inspected a menu and then clicked “back” that a new set of restaurants should appear.

Prototype iteration

Between the rounds of prototyping we made three significant changes.  In the first round, the application opens up to four restaurants already displayed.  In the second round, we open the application by showing our logo in the center of the screen “deal” the four restaurant cards as if they were playing cards.  We chose to do this because we felt that this visual would help solidify in our customers’ minds that each restaurant can be manipulated independently of the others.  After starting our application this way, users no longer expected all four restaurants to leave the screen if they swiped away.  In round one, we allowed users to compare two restaurants side-by-side if they swiped both toward the center of the screen, or if they simultaneously swiped both other options off of the screen.  Not a single test user figured this out.  In round two, we allowed the user to see a fuller menu of a single restaurant by tapping on the restaurant name.  This was the functionality they had expected to get in round one, so we gave it to them in round two.  In this case, all three other options would stack up on the other side of the screen.  Users could then make a second choice of those three to see a side-by-side comparrison.  This turned out to be much more intuitive, and all three of our users in the second iteration figured this functionality out with relative ease.  In round one, the functionality of the single-click had been to take a user directly to the map of how to get to that restaurant.  In round-two that same functionality was achieved by double-clicking a restaurant.  This turned out to make more sense to our users, because a double-click is more confident than a single click, and in our application, a double-click implies that the user wants to go to that restaurant, while a single click simply investigates it further by pulling up our menu.

We also changed how our screen appeard to a user.  In round one, users simply saw four cards arranged in a rectangle.  In round two, users saw those cards appear to be “stacked” on top of other cards.  This way, it was apparant to users that there was more stuff underneath and helped them know that they could swipe the top off of a stack to find stuff underneath.