Scenario and Designs
Scenario
Jess is a graduate student in the Media Lab. She often gets food from the food trucks because they are located near by. There is often a long line when she goes but that does not bother her - she spends the time organizing her thoughts and planning out the rest of her day.
...
Design #1
Task: Creating an Order
Sketch:
Story:
This is the main starting page of the application. When a user wants to order a meal, they first pick a time slot. The time slot is the approximate time when the food will be ready for pickup. Each time slot closes 30 minutes before the delivery time to give the runner time to collect the money and pick up the food.
...
If the user wants to add a new order to the time slot, they simply tap the “New Order” row in the list view. They then are shown a page where they can select the truck, their dish, and add any special instructions.
Learnability:
The UI is consistent with most iOS applications. There is a series of navigational views with a “back” button in the header. The user utilizes their existing knowledge of using iOS apps to guide themselves through the process. The biggest concern here is for new comers that are not familiar with how GroupOrder works. But even for them, the UI is so similar to other apps that they should not have a hard time using it.
Efficiency:
To make the interface more efficient, the user can simply tap the “+1” button that will place the same order for him. Additionally, a user can also select from a list of their previous orders instead of selecting the truck and the dish over again.
Safety:
If the user makes a mistake, they can always go back and edit their order or remove it entirely.
Task: Picking a Runner
Sketch:
Story:
After a user has added their order, they are asked if they are willing to be a runner. A runner will be the person that goes down to the trucks and picks up the food. They are presented with a simple three-option dialog box. This dialog is displayed after the user taps either the “Add order” or “+1” buttons.
Learnability:
The biggest concern here is that new comers may not be familiar with terminology. They may not know what a runner is. We will likely have to include some instructions if they have never been a runner before to help guide them.
Additionally, we could do something cool like if this is a user’s first time as a runner we pair them up with someone who has already done it before. That way, they can teach each other.
Efficiency:
The interface is pretty efficient. There are only three options to pick from. Changing your selection requires a bit more work (see the safety section below) but overall, even that is pretty straight forward.
Safety:
The main safety concern here is if the user accidentally taps “Yes” by mistake. Or, if they tap “Yes”, but then something else comes up and they can’t pick up the food. Their decision can be undone by tapping the “Runner” tab on the bottom of the application. The runner tab will show which time slots they are current the runner for. All they need to do is change their selection here.
Task: Collect Money
Sketch:
Story:
Once a timeslot closes, the runner will be sent a notification and asked to enter into a three part process: collect money, place orders, and notify eaters.
...
Once all of the names are checked off, the UI auto-advances to the next part in the process.
Learnability:
The UI is straight forward. There is a list of names with labels for their location, and the amount of money they owe. There is a “Got it!” button next to their name that the runner can use to keep track of who they have collected from.
Efficiency:
The interface is efficient by showing everyone in a single list. It also sorts the items by their location label, not their name. While this may not work in all cases, it will the runner track people down.
Safety:
The key concern here is accidentally indicating that a person has paid. This is easy to correct - all the user needs to do is hit the check box again and it will reverse the decision.
Task: Place Order
Sketch:
Story:
This is the second screen for the runner - indicated by the dots near the bottom of the UI.
The runner is now near the trucks and waiting in line. He needs to place the various orders at different trucks. This screen shows a list of the meals that need to be ordered organized by the truck. Once the runner places the order, he can simply tap a check box to help him remember which orders he has placed and which orders are pending.
Learnability:
The screen’s learnability is facilitated by its simplicity. The screen is simple a list of orders. The UI makes use of consistent iconography with a “checkbox” so it should be pretty obvious to new comers what is going on.
Efficiency:
To help the runner place orders more efficiently, all of the orders are organized by the truck. Therefore, all he needs to do is pick a line and just read off the list. As he reads, he can check off the orders.
Safety:
There really are no safety concerns with this UI. If the runner accidentally taps the checkbox on the wrong order, all he needs to do is tap it again to uncheck it.
Task: Notify Eaters
Sketch:
Story:
This is the last screen for the runner - indicated by the dots near the bottom of the UI.
Once the runner returns with the food, he is able to send out a notification to let everyone know that their food is ready. Obviously, the runner could personally deliver the food to each individual but that may be too much hassle. Instead, all the runner needs to do is type in where he is and tap “Notify”. A push notification will be sent to everyone who placed an order.
Learnability:
This screen is pretty self explanatory. It conforms to the typical iOS metaphors. To help guide new users, watermarked instructions will initially appear in the “location” text box. Once they tap on the textbox, the instructions will fade away.
Efficiency:
The text box on this screen defaults to the last submitted location. This is helpful if the runner always delivers the food to the same place - for example a lounge or kitchen area. Instead of typing in the location over and over again, all they need to do is tap “Notify”.
Safety:
Given the fact that the text field defaults to the last message, a common error that may occur is that the runner just taps “Notify” out of habit and accidentally sends the wrong location. However, that is okay. The notification screen allows the runner to send out multiple notifications. If they make a mistake, all they do is send out another message saying, “Sorry - the food is actually on the kitchen counter”.
Design # 2
Task: Figuring out what to eat
Sketch:
Story:
On the top is the main page the user gets when the application opens. There are four different actions that can be done. For this task, The user should click on the “browse menus” button. This feature can be accessed without signing in.
On the bottom is the menus page. The user first needs to choose the truck they want to see the menu of, once this is done, the list of all dishes will appear. To change to a different menu, the user needs to open the drop down menu and choose a different truck.
Learnability:
It is very easy to see where to click in order to decide what to order. However, if the user does not know the name of the truck they have in mind, then they’d need to go over the list of all trucks. Also, this interface does not give you any indications as to what kind of food is offered by different trucks.
Efficiency:
Browsing the menus is easy, however, once the users decide what they want, there is no way for them to choose the item and place the order in a fast manor. They would need to go to the place the order section and find the dish their. But the nice thing about the users, is if they common users of this app, then they most probably know what they want to order without checking out the menus.
Safety:
As mentioned in the efficiency section, after the users decide what they want, and proceed with ordering, some forget the name of the dish they wanted so they tend to go back to the menu and check the name and then try to place the order again.
Task: Create a new group order
Sketch:
Story:
If the user needs to add a new group order, then they can click on the “Create a new group order” on the main page (from the first task). Once it has been clicked, then the user need to complete a form with details on the name, location and the active order time for this group.
Learnability:
The main page is pretty easy to navigate through with this task, one click will route the user to creating a new group order. What might not be obvious however, is how to update the group order details once it has been created.
Efficiency:
This task is not a common one, so the aspect of efficiency is not really valued for this part, however, maintaining and updating the group order might be a clear aspect. But creating it is very obvious.
Safety:
If a user creates a group order and later remembers that the information is not accurate, then for safety, the only one who can access and update it is the user who created it. This can be both a good and a bad decision, because if a creator is no longer an action user, then others might end up creating a different group order with mostly the same information. But if all members are able to change information, then there is a safety concern.
Task: Placing Order
Sketch:
Story:
Placing an order is the first in the main page list. Once it’s clicked, then the user gets a page with steps to complete. First is choosing the group order by name. Here, the default is the common one used. Also, the list only includes the active group orders
Second, the user needs to choose 3 dishes, the default for all 3 are the common listed dishes for the user. The reason why there are 3 choices is because in some cases, the trucks might be out of some. There is also the option to get anything else, if the trucks were out of all three.
Third, if the runner had not been chosen yet, then the current user can decide to be the runner. The last step is, based on the order, the user is requested to pay a certain amount (listed) to the (listed) person (if available) or will later get a notification if the runner was not yet selected. The user can then submit their order.
Learnability:
The interface for this task is pretty simple, the steps makes it easier for the user to keep track of things. The one concern the users might face is if the runner was not decided yet, then they would not know immediately who to pay their money to.
Efficiency:
This task is the most common one, therefore listing it first in the main page is great for efficiency. Also, defaulting the group order name and the dishes to the most commonly used is a great way to save time.
Safety:
If the user makes a mistake in any of the sections, then the error is easily revertable by going to view current order section and updating the order again. Also, as part of safety, the creator of the order is the only one who can change it.
Task: Collect Money
Sketch:
Story:
Once the runner has been identified, the application sends a notification to all users within this group with the name and address of the runner (notification appear in the “view current order”). The users need to give money to the runner before the active period is over.If the runner gets money from a certain user, the runs needs to go to “view your current order” tab and click on the paid button next to that user. Once this is done, the user get a paid status update
Learnability:
There are two interfaces for this task, the runner and the other users. The learnability aspect of this task is not quite obvious, user don’t know that they need to go to the “view your current order” page in order to see all these details, however, once the user explores a bit with this interface they quickly learn how to use it.
Efficiency:
This aspect of learnability is very important for this task, because the runner needs to update the status of pay for each user within the group. Hence, it should be very fast to access and updated. From the interface we can see that a paid status can be changed with only one click by the runner, and received immediately by the payer as a notification.
Safety:
Errors can occur if the runner changes the pay status by mistake, but this easily revertable by a click. Also, if the user forgets to pay, then application reminds the user by showing a time left to pay section in the top of the “view current order” tab. These cover the major errors that can occur.
Task: Pick up the food and notify Eaters
Sketch:
Story:
Now that the runner has finally received money from the users, and the active time has passed. The runner goes to the truck, with the list of orders that can be viewed from the “view current order” tab and requests them. If some choices where not available, the runner can order the backup choices for each user. After completing the order, the runner returns back, send a notification with a note, and the location of where to pickup the food from. This is also accessed through the “view current order” tab. As soon as the runner sends the message, all users get it and walk to the given destination, pick up their dishes, and enjoy eating together.
Learnability:
The runner and users can learn how do this task by exploration, as there is not obvious indication how it can be done otherwise. At most, the users need to learn how to send and get final notification twice, since each user can either be only the eater or also a runner.
Efficiency:
The “view/update current order” tab holds all information needed by the runner, as well as the other users. The runner does not need to browse away from the page to get other needed information. This is very convenient for the runner to be able to read off the orders and sending the notifications from the same place. As for the users, once they get the initial notification of the payment, the other notification are easily read.
Safety:
One major issue that might happen is if the runner sends a wrong notification to the users. And even though this action cannot be reversed, the runner could always send another updated notification. No major issues can occur other than this.
Design 3
Task: Figuring out what to eat
This UI assumes that not a lot of detail needs to go into browsing menus, since there are a limited number of food trucks at MIT. The user can select different trucks with a left navigation list, and then view the menu on the right. Trucks which do not have a "runner" associated with them will be greyed out to show that they are inactive. For the sake of simplicity, this UI only allows the user to order food from one truck at a time. This improves efficiency in the ordering flow (physically), but is a limiting factor of the service. However, we notice that it is rare for an individual to go to multiple food trucks, so we feel this is a valid compromise. If the user is unfamiliar with the trucks, this UI doesn't make it easy to explore and filter by food type. Perhaps adding a single description line below the truck name would be an effective addition. (e.g.: Clover: organic sandwiches, fries, and soup.)
Task: Create a new group order
With this UI flow, the user is never shown the details of the group order. This simplification works since the information is not necessary in order to make a decision about what to order. The constraints for delivery time (12:30) and order-by time (11:00) are already set universally. Perhaps an addition could be made here when selecting the delivery location, showing which of your friends have selected the location, suggesting that you can eat lunch with them. Abstracting away the notion of the group order means the user will have a simpler, more traditional experience, but loses the opportunity for changing the order flow based on information about the group. However, these features can always be added later much easier than removed if problematic.
Task: Placing Order
The ordering flow has three distinct stages: picking a truck, selecting food, and entering delivery details. As discussed above, selecting a truck also shows the menu to help inform that decision, but a different interface is provided with the truck is actually selected. This order page lists the menu for the truck, with prices alongside each item. Each item also has a [+] button, which will add the items to a right-side "My Order" list. Clicking the [X] multiple times adds additional items, while the quantity can also be changed on the list. There is also an [X] button for removing the item from your order list. This UI is also simple and does not offer the ability to add notes or have featured deals. Because the ordering process is broken into stages, the user can focus on what food they want to order in this phase, improving the efficiency of the UI. This works because the selection of food is not dependent on other details, such as where it is being delivered or the phone number for notification.
Task: Collecting Money
This UI flow assumes a different pay-on-pickup model, such that the runner does not have to visit offices to collect money beforehand. This puts the burden of fronting the payment on the runner, but drastically improves the efficiency of the entire system. Many people may also not be available to pay before delivery, so this enables those people to use the system. At delivery, the runner has a checklist (likely printed) that they can use to collect money and mark off who has paid or not. A natural extension from this is to enable "tabs" for users, where they reserve payment until the end of the week, for example. This would further increase efficiency, however introduce more risk to the runner.
Task: Delivery and notification
On the final screen of the ordering interface, there are two fields: "Deliver to…" and "Text notification to…". The first allows the user to select from a predefined list of locations where they would like to pickup (and hopefully stay to eat) their lunch. Examples would include "CSAIL 4th Floor Cafe" or "Media Lab 5th Floor Cafe." Once an order is complete, this state is saved such that the next order defaults to the same location. (We assume people will choose labs nearby their own.) Although the food is delivered at a specific time (12:30), users can also optionally enter their mobile phone number to receive a SMS notification when the food has been delivered. We expect this "dinner bell" feature to actually be very popular with colleagues who inadvertently lose track of time and forget to eat. To send this notification, the runner is given a special phone number to text, which broadcasts it to the people who have ordered. This is efficient in that the runner does not need to keep a list of numbers, and also safe since it preserves the user's privacy. This number is also saved by the system so that the user does not need to enter it every time.
Alternate Scenarios
As a group we also explored other scenarios. We felt that the scenario shown above best encapsulated our findings from our user and task analysis. Nevertheless, we brainstormed other scenarios that we thought were also valuable. Those are included here.
...