GR6 - User Testing
Design
Our design was focused on simplicity and visibility. We wanted to allow users to be able to navigate to any page at any time and keep all information easily in view and accessible without crowding the interface with unnecessary widgets or text.
The sign-in/sign-up page was was supposed to convey a concise “Introduction” to our site. We chose to have both the sign-in and the sign-up on the same page because, in our research, the act of having to go to a new page to either sign-in or sign-up was not favored by user testers. The decision we ultimately went with - both on the same page - was favored by user testers.
When a user signed-in or signed-up, we wanted to provide a “User Home Page” which presented him or her with all previous trips and the ability to create new ones. We wanted a centralized directory of all trips which became the Dashboard. With no trips planned, we have by default a message indicating so and an arrow indicating how to plan a trip. Just having the black box with no message was confusing to our users so we added that message. If there are trips in the dashboard, a user may click on the accordion header to see a thumbnail map of the trip, some important information about the trip (dates, places, etc) and the ability to “Remove” the trip or “View” and edit the trip. We wanted to provide the user with the ability to do anything with the previously planned trips. Initially, we had the “Plan a New Trip” button a little below the dashboard box and we found out that this button was sometimes off the screen (the user would have to scroll down). This was made clear to us during the Heuristic Evaluation and we made sure to fix this error in later iterations.
The user may plan a trip by pressing the “Plan a New Trip” button on the Dashboard page. This will take the user to the Planning Page where the user inputs his or her desired trip. We allow the users to title the trips themselves and the rest of the form we wanted to keep consistency with airline forms because “recognition is easier than recall.” We also wanted to add the ability for a “Round Trip.” We added this by adding a “NOTE” on the top of the page, informing users instructions for a round trip to give them the ability to do so.
After a user provides the initial information for the trip in the “Planit” page, the user is taken to the “Map” page. This provides the visual of the trip using Google Maps. Here the user may intermediate stops by clicking "Add Intermediate Stop" as well as see what are the possible hosts in a location when they click the accordion menu for each location under the “Host Options” panel. In this panel, a user may remove the stop or “Send a request” for each person within a stop. Initially we had just a map with “pins” for each stop and a user would have to click on a pin to see which hosts were available in the city. From the paper-prototype testing, this was a poor design choice because user testers became confused as to how select hosts. Hence, we iterated to providing a panel that “kept the map clean” and providing a constantly visual widget that allowed for host selection. Also before, there was a huge inconsistancy between the previous pages and these pages. The backgrounds, buttons, etc. were different between these two sets. This became known to us as an ‘issue’ during the Heuristic Evaluation. On the left of this page we provide a “Navigation” Panel which allows the user to see all bits and pieces of the trip they are currently planning or editing.
The user’s next step is the “Requests” page which can be accessed by either the Navigation Panel or the by clicking on “Send a Request” to a host in the “Host Options” panel on the Map Page. Once here, the user can select hosts in each city to message using the same method in the “Map” page by selecting people from the “Contacts” panel. Users did not seem to have issues with this page.
Finally, the user will want directions so after all the request messages have sent, the user will click on the “Directions” tab on the Navigation Panel which will bring the user to the “Directions” Page. Here the user can view the directions for each leg of the trip. Initially this page only had all the directions. Users thought this was too crowded. We iterated to being able to view the direction by “leg” instead. Users liked this better. Ultimately, as you’ll read in the Evaluation section, this page should keep the “directions by leg” but also present an option to view the entire list of directions.
Now, when a user is receiving requests to be a host, they will arrive in the Messaging Page. Here, users would accept, decline, or maybe the request to be a host. They may also view the request message from the requester and reply to that. Initially we did not have the buttons to “accept” or “decline” or “maybe” the request. Users didn’t seem to like this lack of an option and recommended that having them and using them could be relayed to the requester so that the requester would know as well.
When the user is finished, he or she may log out by pressing the “Logout” button. There were some general, overall bugs that became apparent in User Testing such as broken links/buttons, invalid form submissions etc. But overall during the testing, the users loved having the links/buttons for the Dashboard, Messaging, and Logout along the top bar and having the Navigation Panel on the left when planning a trip.
As mentioned before the main design goals for this project were simplicity and visibility. Recognition was also a primary factor; we did not want to make users learn a new of way inputting information so in general we took pieces of well known things (travel site forms, google maps, etc.) and put them together that would generate user recognition - not recall. The multiple iterations from paper-prototyping, heuristic evaluations and user testing all made for a better product that further met with our design goals.