...
Victor goes back to Facebook and sees these messages in his inbox and is relieved that he has a place to stay in Atlanta. He responds back thanking everyone and opens up Road Trippit. He then finalizes the trip by solidifying the people he is staying with: Maggie in D.C., Stan in Nashville, Mark in New Orleans, and Alexa in Atlanta. He is all set to go!
The day before his trip, Victor downloads and prints off the directions from Road Trippit as well as exporting them to his GPS on his smartphone. He hops in the car and heads to D.C. for his trip.
Designs
Design 1:
1) Home page. Victor logins with his facebook account.
2) Welcome page for first time users. Suggests how to get started and has a preloaded example of how to plan a trip.
...
9) When Victor is ready to be on his way, he navigates to the directions page which shows him step by step directions for his entire trip. He can click the ‘print’ button to print the directions or click the ‘export button’ to export the directions to another device.
Design 1 Analysis:
This design lets the user think of the trip creation as a step by step process. The tabbed interface allows each step in the process to be a distinct page which takes the user from beginning to end one step at a time.
Learnability:
Learnability is probably the main advantage of this design. The tabs on the left side of the page suggest a clear progression of how to create a trip from start to finish. The interface is broken up into small manageable tasks on separate pages so that the user is not overwhelmed and can focus easily on one task at a time. The one downside is that this layout might not make it clear to the user that they can modify any step at any point in the process.
Visibility:
This design has good visibility in the sense that each task is on a separate page which allows the page to be simple and easy to manipulate. The design makes sure that clutter does not become a visibility issue. This design has bad visibility with regard to the fact that the whole state of your trip is not visible at any one time. In order to view the different aspects of the road trip, the user has to change tabs which limits what can be seen at one time.
Efficiency:
The design seems to be fairly efficient. The design does however gives up some efficiency in order to gain better learnability and visibility by using the tabbed interface. It might be somewhat inefficient for the user to have to change between views when trying to modify different aspects of the trip. The user may be viewing the trip map and want to change an intermediate location and might not want to have to change views in order to do that. However efficiency in this regard is sacrificed in order to provide a structured and distinct set of tasks for the user to easily complete.
Error Prevention:
This design has good error prevention. Each field that the user fills in (locations, hosts, dates, etc.) will give suggested completions. Fields will be checked and only accepted if they make sense (real locations, hosts and a timeline that makes sense). Also, every action that user makes can be undone, whether that includes changing locations, changing hosts, or changing dates. The user will be alerted if the change is inconsistent with the rest of the trip that is planned.
Design 2: 
(1) This design starts with a login. Victor would login by pressing the "Login with Facebook" button. This page doesn't have much except a login button which is very simple and learnable. Not much about efficiency or error prevention.
(2) Welcome page (for a first time user - Victor). It talks about the application, what it does, etc. After reading, Victor will click on the "Design a Trip" button to begin planning a trip. This page, like (1) is very simple and learnable with little about efficiency or error prevention.
(3) Plan trip page. Here, Victor inputs his trip name, starting and ending location and the dates he wants to leave and return. The "Roundtrip" checkbox is preselect. Under the preliminary information of Start/End and Dates, is the "Add a Destination" option which, when clicked, allows Victor to add a destination. He clicked it 3 times, inputting Washington D.C., Nashville, and Atlanta as new cities. Each "Added Destination" will also all input for arrival and departure from these intermediate destinations. All "Date" input boxes will have a mini calendar which will allow a user (Victor) to select a date. There is a "Plot Trip" button which will bring the user (Victor) to a page with all of the information including itinerary, hosts, map, directions (see (4)). This page is simple and visible. The user can see all of the information that he inputs and and dates that are chosen. He is quickly able to add new destinations by clicking the "Add Destinations" button which doesn't change the page so everything stays visible. This makes it very learnable as well because this follows the traditional "Travel" site model such as Kayak.com. In terms of error prevention, this page doesn't have much room for actually having errors. Where errors could occur are in the "date selection" boxes and the "roundtrip" checkbox. We prevent errors in the "date" selection by having a mini-calendar which will enforce dates in the right format. These mini-calendars can potentially cover other fields and make them less visible but because we feel that's okay because it forces dates in the right format and prevents errors and when Victor would click out of the calendar or the "x", the calendar would disappear, returning back to full visibility. In terms of the other error of the "preselected roundtrip checkbox," more users planning a trip would most likely want a roundtrip and forget to press it then not wanting a roundtrip and remembering to uncheck it. We think it prevents more errors then it causes.
(4) This is the information page - the bread and butter so to speak. Visibility is number one here and all the information is visible to Victor (the user). He can see his trip itinerary which includes his destinations and dates of travel. He even has the ability to add a location or edit the information. He has a map that plots all of the destinations in the order of dates. Under the map there are directions from each point along the trip to the next point which are able to be printed, emailed, or exported to a smartphone gps interface (google maps, etc.). Victor (the user) also has a panel for hosts. Here He can see all the hosts he has selected for each location. Initially, this panel will list just the locations and no hosts (because no hosts were selected). As Victor (the user) selects hosts for each location, they will be added. He selects hosts by either clicking on the point in the map which will load a bubble of all his friends in that location and he search for a specific friend or pick anyone in that location. He can also select hosts by pressing on the location in the host box which will open the bubble in the map. From this "Hosts" panel, Victor (the user) will be able to send messages to his hosts asking to stay with them. This design of the page presents complete information of the trip (visibility) while still trying to stay simple (nicely organized, etc.). Learnability is relatively good here except the "host selection" may not be so obvious (there is no doubt room to improve here). By clicking the point on the map, one is able to select possible hosts but that might not be so obvious. Hence, by allowing the user to select the city in the "Hosts" panel, he will be able to add hosts because the bubble with friends will pop up on the map as if the user had clicked on the point. We hope that this "linkage" will make the interface more learnable for the user in future trip planning. Some of the errors that could occur here could be that the user (Victor) would print/export the trip without selecting hosts or sending them messages and assuming that messages were sent and confirmed. Perhaps this could be solved by adding a "Message Sent" icon next to each possible host to indicate that a message was sent. We could additionally add a checkmark icon or an "x" icon to indicate that host has accepted or declined to host as well. This would make the interface a lot more visible.
(5) This is the messaging page. By clicking on the "Send Messages" option in (4) in the "Hosts" panel or by clicking on the actual friend option in (4) in the "Hosts" panel, Victor (the user) would be brought to this messaging page. Here, the user can generate messages to send to each possible host. There would be a panel with all hosts and by clicking on one of them, the user (Victor) would be able to see the entire messaging thread. Next to each name in the "Hosts" panel, the user can select "yes" or "no" to show whether a host is confirmed or not. There is also an option to "Return to Trip" so the user can get back. This page is very visible. It shows the entire thread of messaging with each friend. The user can navigate to each message by simply clicking on their name. Further, the user can input whether the host is confirmed or not. Having these options and by keeping the messaging thread similar to the Facebook messaging system, the interface is very learnable. We could improve efficiency by not having to have the user select whether a host is confirmed or not. A possibly better method would be to have, in the message sent to the possible host, a "yes" or "no" button which the recipient of the message would select and it would automatically update the user's (Victor's) road trip information. This is a lot more efficient and prevents the error of the user not updating that information. The con of this is that this page is separate from the main dashboard of the trip; (4). Separating this from (4) allows for simplicity, both in (4) and (5) but it does reduce the visibility of the information for the user (Victor) in terms of the trip information. But having this in the (4) could really clutter that page and make it less efficient, simple, usable. This is the reason we ultimately opted for this separate messaging page with the "link" to get back to the trip dashboard.
Not shown in this scenario is the "My Trips" dashboard which will the user, upon logging in, to see all past, present, and future trips. He will be able to share them, edit them, etc. Hence, each trip, where ever left-off at, will be saved and able to be accessed later. Each trip will be identified by name.