...
Task: Figuring out what to eat
Sketch:
Story:
1) This 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.
2) This is 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 need 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.
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.
...