GR2 - Designs

Scenario 

Storyboard Designs

Design 1:

Design 1 focuses on providing data to an user for they can better decide what restaurant to choose from. The overall purpose of the application is to provide a canvas for the user to eliminate choices to help them narrow down places to eat in a relatively close distance. Starting with more choices, our goal is to provide the user with enough information to narrow a choice from many different restaurants into eventually 1. As we progress to less choices, more and more information will be provided such as detailed reviews and full menus. The idea behind this approach is that users do not needed a lot of information to narrow down initial choices, but as the choices become more difficult, the application provides them with more information to make a better informed decision. 

Storyboard

Initially, the display shows four restaurants in their nearby surroundings with limited information about each restaurant - a name, general rating, distance, and a few menu options. From these choices, the one that seems least appealing can be swiped off, producing another query result. If at any point the user swipes two options off the screen at the same time, the resulting comparison will only look at the remaining two options. Another method is to slide two different restaurants into one other, announcing that the user wants to compare those particular two restaurants. 

This step provides a more detailed comparison between the two remaining choices. Between these two options, the user can again use the same method before, and swipe off the eliminated options, thereby leaving the choice for dinner. 

Once a choice has been made, the application displays a step by step directional map to guide the user to their designation. This page will be displayed with other information about the restaurant, such as phone number, the entire menu, as well as photos of the establishment.

Other Information

This application will contain simple to use back buttons to guard against mistakes and changed decisions. Another feature that will be involved a more traditional sort to limit the type of restaurants that are displayed such as type, price, and rating. This feature will be a part of the middle, MenuMe button. 

Analysis

Learnability: Elimination is a common technique for making choices. Given a certain set of decisions, a person initial instinct is to quickly get rid of choices that are not appealing. Learnability for this particular app follows the same idea. As a user eliminates choices for a restaurant, he can just "wipe" it off the screen. This motion is used throughout the entirety of the experience. As a result, the interaction with our interface is an intuitive way for users to eliminate choices consistant with the way they perform a similar task otherwise. 

Efficiency: Presenting essential information at each particular stage of the elimination process is the key to the efficiency of this design. At our initial level of comparison, our application hopes to provide enough information for a user to eliminate a few of the choices. Later on, as choices are more limited, more information is provided for the user. In the entire searching process, the user rarely needs to navigate between screens to make a decision. 

Safety: A center MenuMe button helps the user navigate through previously swiped options, thereby allowing the user to backtrack through previous choices. Furthermore, additional back buttons will also allow the user to retrace their steps as they look into the menu and location. 

Design 2

Design 3

Design 3 is a radically different way of choosing a restaurant to eat at.  As we have mentioned, the target market is the set of people who are hungry but want cheaper food, and are eating simply to satisfy the biological need, not necessarily to have the "ultimate restaurant experience."  In this design, we allow users to view restaurants in the area, but in the context of a game.  This medium makes a lot of sense for a variety of reasons.  First, since the game can be thought of as "competitive", restaurants could potentially advertise in a new way by rewarding winners.  This way, people would be excited to use the app and find a restaurant that they could get a coupon for.  Second, if we make the game itself compelling enough, people may be excited to use the app just because they enjoy the game.  In this way, we may be able to interest users.  Finally, by giving the user a gaming experience, people could gain an emotional attachment to the restaurant search experience.  That emotional attachment would make it more fun for the user.

The concept of this game goes like this:

The user is in a car driving down the highway.  Every exit is clearly marked with a restaurant and a couple of their "top hit" meals.  When the user wants to exit, he uses the accelerometer, turns the device, and exits.  Upon exiting, he has the choice of finding additional restaurants to compare or continuing the exit and comparing the restaurants he has selected.  The user then compares the restaurants and chooses one.  He can then see a map of how to get there.

The restaurants will be chosen at random from the set of restaurants within 1 mile of the user, according to GPS.  This is an acceptable way to choose the restaurants to display because the user is simply searching for a bite to eat, so he may not know what type of food he wants, but is certainly not picky.  In any case, he can quickly cycle through many restaurants just by "driving down the highway."  See the following storyboard to understand the game on a deeper level:

Storyboard

1) Image 1 shows the first screen a user will encounter.  It has two simple options.  The user can either begin to "race", or cycle through the restaurants.  Otherwise, he can choose "help" to learn more about how to play and choose restaurants.  In our example, our user chooses to "start race".

2) The user has begun searching for restaurants.  His car is driving down the road and sees a billboard at this exit for the restaurant "Hsin Hsin".  If this restaurant is interesting to him, he can take this exit. To do so, he will simply tilt his device right was the exit approaches.  If this restaurant is not interesting to him, he can continue traveling down the road and see the next restaurant.  In our example, assume the user is interested in "Hsin Hsin" and takes the exit.

3) The user has taken the exit for "Hsin Hsin" and is faced with a crossroads.  He can either choose to re-enter the freeway or exit fully.  Re-entering saves this restaurant as a possible choice for the user, which the app will save to be compared later.  Exiting moves the user to a screen where he can learn a bit more about the restaurants he is interested in.  In either case, the user tilts the device to cause the car to turn in that direction.  In our example, the user wants to see other restaurants in the area.  He turns left and is back on the highway as seen in Image 2.  He chooses to compare "Hsin Hsin", the restaurant he has already chosen, to a new restaurant he sees, "Pour House".  This time upon exiting, he fully exits the freeway so that he can "Compare Current" as in Image 3.

4) The user now has found two restaurants he is interested in.  He sees basic information on this screen about the type of food, rating, and popular dishes.  When he finds the one he is interested in, he simply touches that restaurant.  In our example, the user wants to go to "Pour House", so he selects it.

5) Immediately upon selecting the restaurant he wants, a map appears which leads to the desired restaurant.  In our example, the user successfully arrives at "Pour House" and enjoys his meal.

Other Information

This game will contain simple to use back buttons to guard against mistakes, missed exits, etc.  It will also offer a non-game mode where the user simply drives down the road and chooses whether or not to take a given exit at his leisure.  In this use, this application provides a very unique way for users to cycle through possible restaurants in the area.

Analysis

Learnability: This is the hardest part of our application.  The game mode, in particular, will be hard to teach to new users.  People are not yet used to searching for information like restaurants in a time-constrained or game scenario.  We feel that although the learnability could be hard, this isn't a deal breaker because we expect users to enjoy our application often, so they will become "experienced users" quickly.  Further, mobile games are becoming more and more popular in our society, so that aspect should be learnable to most people.  Finally, the potential motivation of having coupons or other rewards for success should help keep users learning the application.

Efficiency: This application will cycle through restaurant choices quickly as the user drives down the road.  Since the user does not need to call the server very often, as we will bring a lot of data down from the cloud before the game begins, this application removes the issue of having to perpetually calling the server and then finding yet a new restaurant and calling the server again.  Finally, we have as few intermediate screens as possible to keep users moving through the application.  Of course, an application could pull the data and display it in a large spreadsheet.  This would be very efficient by uninteresting to use.  As a result, this idea is efficient compared to most options, but we sacrifice optimal efficiency for the sake of user experience.

Safety: The application will have easy to use back buttons that allow a user to rectify any mistakes.  Since we are using accelerometers, there is higher risk of user mistake, so these buttons are even more important.  Every mistake should be rectifiable with a single touch of the screen, so this application will be safe.