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.
...
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.
...
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.
...
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
...
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
...
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.
...
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
...