GR 3 - Paper Prototyping

Prototype Photos (First Iteration)

1. Login page

2. Dashboard for first time users

3. Initial trip planning page

4. Clicking a date field brings up a calendar

5. More location fields after clicking 'Add a Destination'

6. Map of the trip

7. Clicking 'edit' brings up a window to edit the trip

8. Clicking a location brings up a bubble with host information.

9. Clicking 'Add/Change Host' in the bubble brings up window to choose hosts

10. Messaging page

11. Directions page

12. Clicking the 'share' button gives the user options of how to share the trip

13. The dashboard after a trip was created with a yellow indicator meaning that the trip is not yet finalized

Briefing

"Road Trippit" is a road trip planner and organizer aimed for use by college students. Most college students have friends scattered around the country and leveraging their friend networks of Facebook, Road Trippit is a platform that allows users to plan road trips easily and share them socially. By logging in with a Facebook account, you have complete access to your friends around the country and the ability to plan a trip around your social network. A user may plot points of interest, destinations, dates, intermediate locations, message friends and arrange hosting, print directions and share their trip with their friends.

Scenario Tasks

1. Login
2. Plan a new road trip from Boston to New Orleans during the week of Spring Break.
3. Add two intermediate stops during the trip.
4. Select friends in picked locations as a host to message. 
5. Message your chosen hosts asking to stay with them. 
6. Confirm host based on reply of message.
7. Print directions of the trip.
8. Share the trip on Facebook, Twitter, or email.
1. Login

2. Plan a new road trip from Boston to New Orleans during the week of Spring Break.

3. Add two intermediate stops during the trip.

4. Select friends in picked locations as a host to message. 

5. Message your chosen hosts asking to stay with them. 

6. Confirm host based on reply of message.

7. Print directions of the trip.

8. Share the trip on Facebook, Twitter, or email.

First Prototype

Observations

During the first prototype, we used testers that are in the UI class. We observed:

During the first prototype, we observed:
1. Users were confused in the initial planning screen what the "FROM" and "TO" meant. They thought it described input for dates, not locations. 
2. Rather than having the "Add Destination" option on the initial planning screen, users would rather be able to add destinations on the Map View when they can visualize their trip.
3. Users were confused how to actually select possible hosts in the Map View by clicking on the location pointer. They became stuck as to what to do.
4. Users did not like the "Directions" view with directions for the entire trip; they'd rather view directions leg by leg. 
5. In the "Messaging View," users were confused how to select friends; a suggestion was to change the "list of friends" to more of an inbox feel.
6. Users weren't sure about what was shared if they published their trip on Facebook, Twitter, or email concerning what locations, what dates, etc.
7. Users did not know they could select multiple friends at a time when they were picking friends as possible hosts. During the first prototype, we observed:

Second Prototype

Changes

In iterating our prototype, we didn't want to drastically change our design. However, there were certain aspects of our design that needed to change based on the first round of user testing. Specifically, the host selection needed to change because all three of our first round users became stuck in this task. We fixed this problem by having a temporary help message on the screen that showed users that they can select the "location pointer" to bring up a modal box of all their friends in that location. This helped a lot in the second round of user testing; all three of our second round users did not have a problem. We also made some minor changes based on the observations of the first prototype such as the "Direction View" by making it leg by leg, the "Message View" by having a more inbox feel, and describing what was actually published to Facebook, Twitter, or email when the "shared" their trip.

Observations

During the second prototype, we used testers NOT in the UI class but still MIT undergraduates. We observed :

1. When users first selected a point to request hosts, there is a message "Hosts: NONE" which users took to mean that they had no friends in that location.

2. In the "Messaging View" users did not notice that they had to indicate whether or not a host "accepted" or "decline" a request. A user suggestion was to have the host select "accept" or "decline" in their response.

3. Users did not like the "share" option in the "Directions View." They suggested that it be moved to the Dashboard.

4. Two of the users were confused by the colors indicating whether a host was "accepted" (green), "pending" (yellow), or "declined" (red). They suggested some kind of color code. We are not too sure about the color code so we are still brainstorming ideas about that.

Conclusions

We were super surprised by how unclear some of our design choices were. It was great having these iterations because it allowed us to see what was confusing or just didn't work and fix those problems. Further, it allowed to interact with users and see them using our product and realizing what things were bad, despite us thinking they were good in the original design. Finally, it allowed us to fix severe problems in our design such as the host requesting task. We also realized that the paper prototypes didn't allow affordances that would be easier and apparent in the actual implementation. Overall, we have kept the framework of our original design because we believe it simple and sequential but still making the minor changes we observed from users.