...

• Users were concerned with safety, something that we had egregiously failed to address in the carpool search portion of our paper prototype. While originally users could search for any carpool and look up potential carpooling partners' addresses without even logging in, the current version of our site requires the user to input an ID code (that they should have received from the activity instructor) in order to search for their activity. In addition, users cannot view other users until they have logged in.
• Our original interface for swapping dates, which was merged with the My Carpools tab, was very confusing for users because it lacked explanation and was not intuitive. To fix this, we decided to move the swapping interface under its own separate tab because 1) we predicted that it would be a commonly used feature, and 2) if it had its own tab, we would have more space to briefly provide instructions.
• The original form for sending swap requests did not include the names of the other users with whom the user would be swapping because we did not think that information would be relevant. However, most test users indicated that they were interested in knowing who they would be swapping with, so we decided to change our form to include this.
• The original form for accepting swap requests was inefficient because it involved multiple steps, which were somewhat redundant with each other. We decided to condense the form into a single step.
• For the web app overall, we noticed that the ordering of the tabs from left to right was important; users stopped scanning once they thought they had found what they wanted, failing to realize that we had included shortcut tabs further to the right. We decided to reorder the tabs so that shortcut tabs, such as Next Date and Swap Dates, would be located further to the left and thus appear more immediately obvious to the user.
• In the paper prototype of our mobile app, the option to enable ride tracking was confusing for users. The original wording on the button was "Track Ride," which didn't make sense because users couldn't understand why they would want to track their own ride. To fix this, we changed the wording to "Enable Ride Tracking."

Heuristic Evaluation

User Testing

...

• For the Next Dates tab, one of our evaluators suggested that we remove the Confirm Date button and change the Swap Times button to a link that said, "Can't make this time? Try swapping." We agreed with this suggestion because we predicted that a lot of parents would forget to confirm, which would only lead to confusion; we agreed that changing the button for Swap Times was a good idea for the sake of external consistency with other web apps.
• One of our evaluators pointed out the safety concern of not being able to see outgoing swap requests. They also complained that the interface was not as intuitive as it could be. We decided to redesign the Swap Dates tab to closely resemble Gmail's interface, so it would be more intuitive for users by taking advantage of external consistency. Users can now keep track of outgoing requests by viewing My Sent Requests.
• Both evaluators pointed out efficiency problems with not being able to easily access the user's full schedule. We decided to add a separate tab for this, My Full Schedule, so that the user would be able to find their calendar easily.
• For the mobile app, one of our evaluators suggested that we add more functionality to the mobile app so that it would more closely resemble the web app. We realized that they had not understood that the intended purpose of the web app was merely to allow users to enable ride tracking. We changed the title of the mobile app to "Ride Tracking App" in order to make this more obvious.
• In studio, a classmate pointed out that the home screen for our mobile app looked identical to the screens for the carpools; the only difference was the text on the buttons. We decided to invert the background colors for the carpool screens in order to establish a contrast.

User Testing

Implementation

-Details-

Evaluation

...