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: 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.
Wiki Markup
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.
...