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.
(Home page to signin/signup)
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.
(Empty Dashboard with instructions to Plan a New Trip)
(A Dashboard with a trip already made).
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.
(The Plannit box to plan trips)
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 Map Page)
(The "Add Intermediate Stop Modal Box)
(The "Host Options for each city)
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.
(The Requests 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.
(The Messaging Page)
(The Modal Box for a message thread)
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.
Implementation
In implementing this project, our goals included a front-end and back-end. However, as written in the Reflection section, the back-end goals were difficult to meet with our group of only 2 people. With that said, our implementation focused on the front-end User Interface. We implemented the User Interface with HTML, CSS, Google API, Javascript, Jquery, JqueryUI, and a number of other small libraries like JqueryCorner. The Front-End functionality was implemented in Javascript using the OOP features of the language.
The choice of these libraries were because they provided good features for a UI. For example, in some of our online research, we found that boxes with rounded corners are much more visually pleasing then straight corners.
In formatting the pages of the site, we used CSS to construct the layout. We reused a lot of the css from page to page to keep pages consistent - such as the Dashboard Page and the Plannit Page. Another CSS feature we utilized was the opaqueness. This was another feature we found that had a “visible appeal.”
In terms of the “dynamic” aspect of the site, we utilized the JavaScript Libraries such as Modal Boxes, accordions, buttons, etc. from JQuery and JQueryUI. For example, we store a user’s trips in the Dashboard using an accordion and we allow messaging using Modal Boxes.
The API implemented was from Google Maps. This provided a visual representation of the trip that was planned as well as directions for users for each leg.
The back-end functionality was actually implemented in Javascript in the front-end. There was not enough time or labor to implement an minimal and functional backend. However, our back end design consisted of PHP and MySQL. We would store a user’s trips in the database and pull them when the user logged in to populate their dashboard and messaging. Additionally, when messages were sent, they would be stored in the database associated with the user that the message was addressed too. However, the form error handling, sometimes done in the back end was always intended to be implemented in the front end.
One final shortcoming in our original goal was the implementation of the Facebook API. There was not enough time for the two of us to include it in the way we wanted to with everything else that had to be done. This was not a priority but nonetheless would have been great to use.
The UI is built to include the Facebook API, however. For example, in the “Host Options” panel, where there are a number of hosts in each city, each of those spaces are divs that allow for a picture and name of a Facebook Friend of the user in that location. Currently, they are only ‘canned’ hosts which are distributed randomly between locations.
In terms of the implementation hindering the UI, there was nothing that was explicitly hindered. The UI is what was focused on mostly in the entire implementation because the backend was never implemented. However, because the front-end was all implemented in JavaScript, HTML, and CSS, we lost the opportunity to use other graphic techniques to better the UI such as using Photoshop, etc.
Evaluation
The target user population for RoadTrippit is both male and female students age 18-22. To find users for user testing we simply asked fellow MIT students as they are exactly the type of user RoadTrippit is intended for. We found users that expressed interest in travelling while in school and were open to using a service to help them plan and organize their road trip.
Each user was given a short briefing before testing. The user was told that RoadTrippit is a website that allows them to both plan a road trip and help other students by hosting them while they are on their own trip. The user was also informed that due to the limited scope of this project, the hosts that RoadTrippit would suggest for a road trip would be completely fictional but that every other aspect of the site was functional.
A demo was not performed for the user as we were interested in seeing how a user would respond to the interface without having seen it before. We felt that our interface was simple enough that a user should be able to use it without having to have seen it in use.
Each user was asked to complete the following tasks:
- Create a new trip that goes from Boston to New York and has at least four stops total.
- Send a request to at least one of the suggested hosts for one of the cities.
- Confirm a host for each stop of the road trip.
- View the directions for each leg of the road trip.
- View the request you have received.
- Remove the trip you just created.
- Create a round trip starting in Boston.
Usability Problems Discovered
- Problem: Planning a first trip required the user to find a button in the bottom right hand corner of the screen. The user felt that the instructions and graphic alerting the user to this button was unnecessary.
Severity: minor
Solution: The initial dashboard should have a large centered ‘plan new trip’ button instead of trying to keep the interface the same as the dashboard that already has trips planned.
- Problem: One user had trouble figuring out how to plan a round trip. They weren’t helped by the note above the planning box the explains it.
Severity: major
Solution: Instead of having a note that informs the user of how to plan a round trip, have a ‘round trip’ check box that when clicked automatically sets the ‘start’ and ‘destination’ fields to the same location for the user.
- Problem: The interface allows for trip dates that don’t make logical sense.
Severity: minor
Solution: Check the dates that were entered and stop/alert the user when the end date
before the start date for example.
- Problem: When a city is entered into the location field that does not exits, the map page shows a blank map without an error message.
Severity: major
Solution: Check to make sure the entered location is a real city. If not, alert the user and
ask for the location again.
- Problem: When the user clicked on a suggested host on the map page, to view that host’s location the user had to manually adjust the map.
Severity: minor
Solution: Clicking on a city under host options should cause the map to focus in on that city.
- Problem: User was confused why they could add a new start or end location to the trip.
Severity: minor
Solution: User should be allowed to change the starting or ending location.
- Problem: User didn’t like that sending a request to a suggested host took them away from the map page.
Severity: minor
Solution: User should be able to send a request without having to leave the map page. It should be a modal dialog box that disappears after the message is sent. To view the message the user would then go to the requests tab.
- Problem: Users were confused if they confirmed a host or if the host confirmed themselves as both options were available.
Severity: Major
Solution: Make two different types of confirmation/declining. Have one indicator of whether the host has accepted or declined your request. Have a separate indicator for whether you have decided to use that host or not.
- Problem: User didn’t like that in the directions page, after clicking on a city on the itinerary to view the information, to view the direction the user had to cycle through the other legs of the trip.
Severity: Major
Solution: Clicking on a city in the itinerary in the directions section should automatically load that leg of the directions.
- Problem: User couldn’t find a way to view all directions at once for the trip.
Severity: Major
Solution: There should be an option to see the directions for the entire trip, not just one leg.
- Problem: A user viewed a request but wanted to know information about the trip of the person who had sent that request.
Severity: minor
Solution: If the user gets a request from another user, that user should be able to view the itinerary of the other user’s trip.
- Problem: The word ‘return’ is used for the date field of the last stop. This terminology is confusing for trips that are not round trip.
Severity: minor
Solution: Use a different word like ‘End’ or ‘Finish’
Reflection
This project allowed us to learn about many important aspects of the design process. The most important thing we learned throughout this process was the importance of constant user feedback. After each iteration we were very pleased with our design. However, only after user testing did we realize how many problems the design actually had.
After each round of user testing, our design made huge leaps forward in terms of usability. For this project we only did user testing after the paper prototype, the computer prototype and the final iteration for a total of three times. In retrospect we should have done more user testing than was required for the course.
We found that the paper prototyping was the most useful. The amount of time and resources required to create a paper prototype was very minimal and the amount of useful feedback was great. Our design would probably have benefited from many more rounds of user testing on paper prototypes. We were unable to do so because of the amount of time we had and the pace we had to keep in order to finish the project by the end of the semester.
We also learned not only the importance of testing users to find usability problems but also listening to users in order to find the best way to fix the problems. In most cases, the solutions to usability problems that arose during user testing were suggested by the user that was having that particular problem. Even though we had an idea of what features we wanted to have implemented, actual users proved to be extremely important in determining how the features should be implemented.
As important as we found listening to users to be, we also learned to make sure that a usability problem was consistent among different users. There were times when one specific user had trouble with the interface and we considered making changes to alleviate that problem but discovered that this user was unique and that making a change might negatively effect the usability for almost all other users. In other words, we learned to update our design based on common user problems rather than trying to address every single issue that every single user had.
An issue that we had during this project was implementing all the features that we had planned during the initial design phase especially given that we had only two group members. If we were to do this project again we would make an effort to do a better job of determining the features that would be realistic to implement in less than one semester with only two people.
We spent much of the early design phase crafting and testing interfaces for features for which we didn’t spend enough time thinking through whether it was reasonable to actually implement in the short time we had. We then had to spend most of implementation time during the end of the project on the back end and were forced to focus much less on improving the actual interface and user experience of the site.
In the end we had to scrap the back end as well as many key features that we had set out to implement and our user interface suffered because of this. If were to do this project again we would focus on implementing simple features very well rather than trying to implement very complicated and interesting features.