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. For example, out of the four displayed options, Subway seems the be the least attractive, I will just swipe it off the screen and see what else the application suggests. At any point in this process, the user may also click on the restaurant of their choice to see a more detailed report on the establishment. 

After looking through a few different options, the user is please with his choice of four restaurants, and now has decided on two that he want to examine further. 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. Additional choices can also be to click on the selected choice, at which point that will application will interpret it as the user's choice. 

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 "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:

This design is based on a compass.  When a user chooses to open our application, he can basically point the device in a direction and see what restaurants are in that direction.  The motivation for this is that sometimes a user may have some notion of which way he is trying to go.  In this application he can easily see what is in that direction.  This application will eliminate the obnoxious "pins" that tend to show up in current restaurant map searches.  Additionally, it doesn't require the user to read any sort of map to see what direction his desired restaurant is in.  He can instead find restaurants in a more intuitive manner since the device is a part of the user's world, instead of simply showing a top view of the world.  Finally, when we ultimately do show the user a map so that he can get there exactly, he is already oriented as to which direction he should begin walking.  This will make the process of reading the map eventually much easier.just

Storyboard

1) Image 1 shows the first page a user sees when opening the application.  It looks like a compass, showing that Wendy's and McDonald's are straight ahead, more or less.  The user can also see the cardinal direction for orientation.  If the user turns his device one direction or another, the restaurants being showed will rotate and new restaurants will appear.  The restaurants always represent a few that would be found if the user headed in that direction.  In our example, suppose the user is interested in sorting the restaurants that are shown in a different way.  He touches the "sort" button.

2) Image 2 shows a simple menu of the different ways the application can choose to show restaurants.  Since there are presumably many restaurants in a given direction, the user can choose which types he wants to see.  Our user is very interested in getting cheap food, so he selects "cost".  The menu disappears and the compass reappears as in Image 1.  The user now finds two restaurants that interest him.  He adds them to a list of restaurants he wants to compare by touching them.  Once he has found two that he likes, he selects "compare".

3) Image 3 shows the two restaurants our user is interested in.  If he changes his mind and wants to continue searching, he can simply press "back".  Otherwise, he selects the restaurant he wants.  In our case, the user wants to go to "Hsin Hsin".

4) Image 4 shows a map that the user can follow to his destination.  Our user does so and enjoys his experience.

Further Information

The map in Image 4 is something that we are wrestling with a lot.  It would be more consistent and very cool if after the user selected his restaurant, he was directed by a compass to the destination.  In other words, he would be directed by an interface more like that shown in Image 1.  We chose not to use that idea in this storyboard because we are concerned about the accuracy of the directions people would get, as well as the accuracy of the GPS knowing exactly where the user is.  If we choose to implement this design, we will seriously consider implementing our design in this way.

Additionally, there is the concern of how we show multiple restaurants in the same direction.  Since our expected user is not super picky about the place he eats, but instead is just trying to find some food, showing only a few restaurants in a given direction is acceptable.  We are working out the best way to add some sort of scroll bar, though, to cycle through the various restaurants at various distances in a given direction.  It is a minor detail at this point, but we are thinking about it.

Analysis:

Learnability: This should be very learnable, because the idea of pointing the device in the direction you want to find a restaurant seems very intuitive.  A user should be able to pick up the app, and even if he doesn't know what it does, just by turning it and seeing various restaurant logos scrolling on the screen, a new user can learn what the app is doing.  The subsequent screens are very self-explanatory and there are few controls.  That means that a user will not have to learn very much functionality to fully use this application.

Efficiency: The main concern here is that a user will have to physically move the device to see all the restaurant options.  This is a very slow process.  This may be an acceptable tradeoff, though, if the user feels that the search is more intuitive and interactive.  Once the user has chosen his restaurants, the rest of the process is very quick, as there are very few steps to take, and all can be completed with a simple touch.  Another concern here is that the process of scrolling through the restaurants in a given direction may be time consuming and tedious for the user.  We are designing this for a user who doesn't care too much, though, so we shouldn't find users who want to scroll through tons of restaurant options.  In any case, efficiency is where we see a primary concern, because the user does have to physically move the device to select a restaurant.

Safety: We will have back buttons to easily return to previous screens.  This will mitigate a lot of safety concerns.  The largest safety concern is that after the user has chosen his restaurants, if he makes a mistake and wants to re select his restaurants, the nature of the compass interface is tricky.  He will then have to point the device in the proper directions once again to find the restaurants he wants.  This could be very annoying for many users as they are effectively forced to start over.  This should be a solvable issue, though.  We will continue developing solutions to this issue that mitigate the safety concerns while maintaining consistency with the design of the app.

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.